Method and Apparatus for Operating Networked Gaming Devices

ABSTRACT

A system for monitoring and configuring gaming devices interconnected over a high-speed network is disclosed. The system can support a file server, one or more floor controllers, one or more pit terminals, and other terminals all interconnected over the network. Each gaming device includes an electronic module which allows the gaming device to communicate with a floor controller over a current loop network. The electronic module includes a player tracking module and a data communication node. The player tracking module includes a card reader for detecting a player tracking card inserted therein which identifies the player. The data communication node communicates with both the floor controller and the gaming device. The data communication node communicates with the gaming device over a serial interface through which the data communication node transmits reconfiguration commands. The gaming device reconfigures its payout schedule responsive to the reconfiguration commands to provide a variety of promotional bonuses such as multiple jackpot bonuses, mystery jackpot bonuses, progressive jackpot bonuses, or player specific bonuses.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of prior application Ser. No.11/118,163, filed Apr. 29, 2005, which is a continuation of priorapplication Ser. No. 10/932,615, filed Sep. 1, 2004, which is acontinuation of prior application Ser. No. 09/827,870, filed Apr. 6,2001, which is a continuation of prior application Ser. No. 08/922,046,filed Sep. 2, 1997, now U.S. Pat. No. 6,257,981, which is a continuationof application Ser. No. 08/465,717, filed Jun. 6, 1995, now U.S. Pat.No. 5,836,817, which is a divisional of application Ser. No. 08/322,172,filed Oct. 12, 1994, now U.S. Pat. No. 5,655,961.

BACKGROUND OF THE INVENTION

This invention relates generally to gaming devices, and moreparticularly to a method and apparatus for controlling gaming devicesinterconnected by a computer network.

Networked gaming devices are know in the art. Interconnecting aplurality of gaming devices such as slot machines via a computer networkto a central computer provides many advantages. The primary advantage ofnetworked gaming devices is the ability to extract accounting data fromthe individual gaming devices as well as providing player tracking. Anexample of a data collection system is described in U.S. Pat. No.4,283,709 issued to Lucero et al. Network systems such as described inLucero et al. allow the central host computer to monitor the usage andpayout, collectively known as audit data, of the individual gamingdevices. This audit data includes data related to the number of coins ortokens inserted into the device, the number of times the device has beenplayed, the amount paid in raises, the number and the type of jackpotspaid by the machine, the number of door openings, etc. The host computercan then compile an accounting report based on the audit data from eachof the individual gaming devices. This report can then be used bymanagement, for example, to assess the profitability of the individualgaming devices.

Player tracking, as the name indicates, involves tracking individualplayer usage of gaming devices. In prior art player tracking systems,the player is issued a player identification card which has encodedthereon a player identification number that uniquely identifies theplayer. The individual gaming devices are fitted with a card reader,into which the player inserts a player tracking card prior to playingthe associated gaming device. The card reader reads the playeridentification number off the card and informs a central computerconnected thereto of the player's subsequent gaming activity. Bytracking the individual players, individual player usage can bemonitored by associating certain of the audit data with the playeridentification numbers. This allows gaming establishments to targetindividual players with direct marketing techniques according to theindividual's usage.

One problem that can occur with current player tracking systems is thatthe player can insert a player identification card incorrectlyunbeknownst to the player. Currently, if a player inserts a playeridentification card improperly into the card reader, a message appearson a display located away from the card reader. Unfortunately, theplayer may not be looking at the display while inserting the card. As aresult, the player may not see the message on the display. Another priorart approach has been to provide a light emitting diode on the gamingdevice to indicate to the player the status of the card insertion. Thistoo has been ineffective because the player may not know the purpose ofthe LED or the LED may be drowned out by all the other lights of thecasino. The player may therefore commence playing with the cardimproperly inserted. In this case, both the player and the casino losevaluable player tracking information. This is frustrating for the playerbecause his activity will not be credited to his account and frustratingfor the casino because the casino's records will be incomplete.Accordingly, a need remains for an improved method and apparatus forinforming the player when a player tracking card has been improperlyinserted.

The full power of networked gaming devices has not been completelyrealized. Although the audit data indicates which devices are beingunder utilized and when, there is currently no automated method foraltering under utilized gaming devices' configurations to make them moreattractive to play. For example, during certain hours of the day, e.g.four to six a.m., the audit data may indicate that the machines arebeing under utilized. Thus, it would be desirable to reconfigure theunder utilized gaming devices to provide an additional incentive toplayers to use these devices. In the past casinos have run “bonuses”during these times. An example of such bonuses include a “doublejackpot” wherein a player hitting a jackpot is paid double the jackpotamount. Currently this is implemented by having an attendant manuallypayout the additional payout amount. This manual technique, however, iscumbersome and inefficient to administer because an attendant must beconstantly supervising the bonusing gaming devices. Accordingly, a needremains for an automated method and apparatus to provide bonusing forgaming devices.

Another limitation of the current bonusing systems is that onlypredetermined machines are eligible for the bonusing. For example, in aprogressive bonusing machine a plurality of machines are connectedtogether to form a bank. Only the machines in the bank are then eligibleto win the progressive jackpot. Thus, a casino must dedicate a certainnumber of its machines to these banks. This limits the casino'sflexibility in tailoring its bonusing to the number and make-up of itscustomers. Accordingly, a need remains for a more flexible bonusingsystem whereby any of the casino's machines can participate in thebonusing.

SUMMARY OF THE INVENTION

It is, therefore, an object of the invention to reconfigure gamingdevices remotely over a network to provide bonusing.

Another object of the invention is to provide an integrated systemusable with a variety of gaming devices made by different manufacturers.

Another object of the invention is to integrate player tracking, datacollection, and bonusing over the same network.

A further object of the invention is to provide visual feedback to theuser when a player tracking card has been improperly inserted.

A system for operating networked gaming devices is described. The systemaccording to the invention allows a casino in which the system isinstalled to run promotions or bonuses on any properly equipped gamingmachines while simultaneously gathering player tracking and accountingdata from all machines. The system provides the capability for thecasino to select which of the plurality of machines are used in anygiven promotion. The system further allows any number of differentpromotions to operate simultaneously.

The system includes a plurality of gaming devices or machines connectedto an associated floor controller over a network. The system includesone or more of said floor controllers. The floor controllers areinterconnected by a high-speed network, such as an Ethernet network, toa database where accounting and player tracking data is stored. Thesystem can also include pit terminals and/or fill and jackpot processingterminals. Each promotion involves sending a reconfiguration commandfrom the floor controller to a gaming device that has been selected tobe part of a given promotion over the associated network. Upon receiptof the reconfiguration command, the gaming device reconfigures itspayout schedule in accordance with the received reconfiguration command.In the preferred embodiment, this reconfiguration includes activating abonus payout schedule. A partial list of the promotions according to theinvention include, but are not limited to: a multiple jackpot whereinthe gaming device reconfigures its payout to be a multiple of itsdefault payout schedule; a bonus jackpot wherein the gaming devicereconfigures its payout schedule to payout an additional bonus amountwhen certain conditions are met; and a progressive jackpot wherein twoor more gaming devices are combined in a progressive jackpot having aprogressive jackpot payout schedule. In addition to these, many otherpromotions are possible by the above-described system for controllingand monitoring a plurality of gaming devices.

The system also allows for improved player tracking by recording eachand every machine transaction including time of play, machine number,duration of play, coins in, coins out, hand paid jackpots and gamesplayed. The player tracking is conducted over the same network as theaccounting data is extracted. This allows the invention to providebonusing to certain individual players as well as during certain times.As with standard player tracking, the above-described system monitorsand reports how many coins are played by each player. The systemaccording to the invention, however, also includes the ability to recordhow long each player spends at each machine and the number of coins won,games played, and hand jackpots won by each player. The invention isable to record all this information because the system operates on atransaction by transaction basis. Each transaction, whether it be a coinin, a handle pull, etc., is recorded by the system. Other systems simplycompile the player tracking information at the completion of play. Allthis information is stored on the database, which can be later analyzedfor future targeted direct mailing campaigns. The player trackingaccording to the invention also allows the casino to schedule buses andother groups and measure their profitability. The system also allows forcashless play as well as advanced accounting and security features.

An advantage of the invention is that any of the casino's machines canbe incorporated into a bonus promotion.

Another advantage of the invention is that several bonus promotions canoperate simultaneously.

A further advantage of the invention is the ability to record each andevery machine transaction including time of play, machine number,duration of play, coins in, coins out, hand paid jackpots and gamesplayed.

A further advantage of the invention is the ability to associate aplayer with a certain machine.

A further advantage of the invention is the ability to perform moretargeted direct mailing based on individual play.

A further advantage of the invention is the ability to calculate atheoretical win exactly.

A further advantage of the invention is the ability to generate jackpotannouncements, which provides for, among other things, better slottournaments.

A yet further advantage of the invention is the ability to quickly andeasily add new machines to the network.

The foregoing and other objects, features and advantages of theinvention will become more readily apparent from the following detaileddescription of a preferred embodiment of the invention which proceedswith reference to the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is an illustration of a system for monitoring and configuringgaming devices according to the invention.

FIG. 2 is a block diagram of an electronic module associated with eachgaming device to permit monitoring and configuring thereof.

FIG. 3 is a schematic diagram of a data communication node of theelectronic module of FIG. 2.

FIG. 4 is a schematic diagram of a discrete machine interface circuit ofthe electronic module of FIG. 2.

FIG. 5 is a schematic diagram of a player tracking module of theelectronic module of FIG. 2.

FIG. 6 is a schematic diagram of a card reader circuit of the electronicmodule of FIG. 2.

FIG. 7A is an exploded view of a card reader according to the invention.

FIG. 7B is a rear perspective view of the card reader of FIG. 7A.

FIG. 7C is a front perspective view of the card reader of FIG. 7A.

FIG. 8 is a schematic diagram of a display circuit of the playertracking module of FIG. 2.

FIG. 9 is a schematic diagram of a personality board of the electronicmodule of FIG. 2.

FIG. 10 is a schematic diagram of a triac driver circuit of theelectronic module of FIG. 2.

FIG. 11 is a schematic diagram of a relay driver circuit of theelectronic module of FIG. 2.

FIG. 12 is a block diagram of a communication board included in eachfloor controller of FIG. 1.

FIG. 13 is a flow chart for the power-on procedure for the datacommunication node (DCN) of FIG. 2, which is implemented in firmwareexecuted by the DCN controller.

FIG. 14 is a flow chart for processing of the discrete gaming deviceinputs, of FIG. 13.

FIG. 15 is a flow chart for the step of incrementing meter countsassociated with each gaming device of FIG. 14, which is implemented infirmware executed by the DCN controller.

FIG. 16 is a flow chart for the step of processing the serial interfacebetween the gaming device and the data communication node of FIG. 13,which is implemented in firmware executed by the DCN controller.

FIG. 17 is a flow chart for the step of processing the network interfacebetween the floor controller and the data communication node of FIG. 13,which is implemented in firmware executed by the DCN controller.

FIG. 18 is a flow chart for the step of processing the network messageof FIG. 17, which is implemented in firmware executed by the DCNcontroller.

FIG. 19 is a flow chart for the step of processing the datacommunication node request of FIG. 18, which is implemented in firmwareexecuted by the DCN controller.

FIG. 20 is a flow chart for the step of FIG. 13 of processing the playertracking interface, which is implemented in firmware executed by the DCNcontroller.

FIG. 21 is a flow chart for the step of processing a valid inserted cardof FIG. 20, which is implemented in firmware executed by the DCNcontroller.

FIG. 22 is a flow chart for the step of processing player trackinginformation of FIG. 21, which is implemented in firmware executed by theDCN controller.

FIG. 23 is a flow chart for the power-on procedure for the playertracking (PT) node of FIG. 2, which is implemented in firmware executedby the PT controller.

FIG. 24 is a flow chart for the step of processing the DCN interface ofFIG. 23, which is implemented in firmware executed by the PT controller.

FIG. 25 is a flow chart for the step of processing the DCN message ofFIG. 24, which is implemented in firmware executed by the PT controller.

FIG. 26 is a flow chart for the step of processing the card reader bezelupdate of FIG. 23, which is implemented in firmware executed by the PTcontroller.

FIG. 27 is a flow chart for the step of processing the card reader ofFIG. 23, which is implemented in firmware executed by the PT controller.

FIG. 28 is a flow chart for the power-on floor controller process, whichis implemented in software executed by the floor controller.

FIG. 29 is a flow chart for the message processing step of FIG. 28,which is implemented in software executed by the floor controller.

FIG. 30 is a flow chart for the message handling step of FIG. 29, whichis implemented in software executed by the floor controller.

FIG. 31 is a flow chart for the step of assigning unique machineaddresses of FIG. 30, which is implemented in software executed by thefloor controller.

FIG. 32 is a flow chart for the system monitoring step of FIG. 28, whichis implemented in software executed by the floor controller.

FIG. 33 is a flow chart for the event handling step of FIG. 32, which isimplemented in software executed by the floor controller.

FIG. 34 is a flow chart for bonus control, which is implemented insoftware executed by the floor controller.

DETAILED DESCRIPTION TABLE OF CONTENTS

I. SYSTEM ORGANIZATION

A. SYSTEM OVERVIEW

B. DATA COMMUNICATION NODE

-   -   1. OVERVIEW    -   2. CONTROLLER AND MEMORY    -   3. NETWORK INTERFACE    -   4. SERIAL MACHINE INTERFACE    -   5. SERIAL DISPLAY INTERFACE    -   6. DISCRETE MACHINE INTERFACE    -   7. MACHINE CONFIGURATION

C. PLAYER TRACKING MODULE

-   -   1. OVERVIEW    -   2. SERIAL DISPLAY CIRCUIT    -   3. SERIAL EXPANSION PORTS    -   4. CARD READER    -   5. DISPLAY    -   6. DISCRETE INPUT SECTION

D. PERSONALITY BOARD

E. BONUS DISPLAY DRIVERS

F. FLOOR CONTROLLER

II. OPERATION

A. DATA COMMUNICATION NODE

-   -   1. POWER UP PROCEDURE    -   2. READING UNIQUE IDENTIFICATION NUMBER    -   3. MONITORING GAMING DEVICE DISCRETE INPUT    -   4. PROCESSING GAMING DEVICE SERIAL INTERFACE    -   5. PROCESSING NETWORK INTERFACE    -   6. PROCESSING PLAYER TRACKING INTERFACE    -   7. PROCESSING CARD INSERTION

B. PLAYER TRACKING MODULE

-   -   1. POWER UP PROCEDURE    -   2. PROCESSING DCN INTERFACE    -   3. PROCESSING DISPLAY UPDATE    -   4. PROCESSING BEZEL UPDATE    -   5. PROCESSING CARD READER

C. FLOOR CONTROLLER

-   -   1. POWER UP PROCEDURE    -   2. MESSAGE PROCESSING    -   3. ASSIGNING GAMING DEVICE ADDRESSES    -   4. SYSTEM MONITORING    -   5. BONUS CONTROL

I. System Organization

A. System Overview

A system for operating a plurality of gaming devices is shown generallyat 10 in FIG. 1. The system, hereinafter described, monitors andreconfigures a plurality of gaming devices or machines 12-16 and 22-26.The system includes the following capabilities: remote reconfiguration,accounting data extraction, integrated player tracking, and cashlessplay. Remote reconfiguration includes sending a reconfiguration commandfrom a host computer to one or more of the gaming devices. The gamingdevices, on receiving a reconfiguration command, will reconfigure itsjackpot payout schedule in accordance with the reconfiguration command.

This reconfiguration, in the preferred embodiment, comprises activatinga bonus payout schedule. This bonus payout schedule is in addition tothe normal pay table of the gaming device. The bonus payout scheduleprovides for additional bonus payouts in addition to the payoutsspecified by the device's normal pay table. The difference between thetwo is important for regulatory reasons. The composition of the paytable is subject to regulation by the various state gaming commissionswhile the bonus payout schedule is not. The preferred embodimentcurrently activates only the bonus payout schedule responsive to thereconfiguration command, while not altering the payout table. Theinvention, however, is not limited to activating only the bonus payoutschedule. Other embodiments, which would be subject to regulatoryapproval, could modify the device's payout table. The preferredembodiment, however, does not.

The system, according to the invention, implements a variety of bonusingevents through this reconfiguration process. These bonusing eventsinclude: a multiple jackpot wherein the gaming device reconfigures itspayout to be a multiple of its default payout schedule; a bonus jackpotwherein the gaming device reconfigures its payout schedule to payout anadditional bonus amount when certain conditions are met; and aprogressive jackpot wherein two or more gaming devices are combined in aprogressive jackpot having a progressive jackpot payout schedule.

The system, according to the invention, also provides for integratedplayer tracking and accounting data extraction. Unlike prior art systemsthat use disparate systems for player tracking and accounting dataextraction, the system 10 provides for player tracking and accountingdata extraction over the same network. The player tracking, according tothe invention, allows the casino to run certain promotional events. Theintegrated player tracking and accounting data extraction also allowsthe system to support cashless play wherein a credit is given to aplayer over the network.

The system 10 includes one or more floor controllers 18 and 28. Eachfloor controller supports up to a predetermined maximum number of gamingdevices. In the preferred embodiment, each floor controller can supportup to 1024 gaming devices. The preferred embodiment also supports up toeight floor controllers. Thus, the system 10 can support up to 8192separate gaming devices.

The system supports a multiplicity of various gaming devices. The gamingdevices 12-16 and 22-26 shown in FIG. 1 are the type having a pullhandle for initiating a game, e.g., slot machines. However, theinvention is not limited to such gaming devices. The gaming devicesshown in FIG. 1 can also be gaming tables or push button operatedmachines as well, e.g, video poker. As will be described hereinafter,the system supports any gaming device providing traditional discreteconnections, e.g., coins-in, coins-out, etc., as well as those havingserial interfaces, as described below.

The floor controllers 18 and 28 are, in the preferred embodiment,IBM-compatible personal computers. Each floor controller is responsiblefor monitoring the activity level of the corresponding gaming devicesconnected thereto and issuing commands to the associated gaming devicesto reconfigure their payout schedules during certain bonusing events.The floor controllers issue status requests to each of the individualgaming devices to determine the activity level of each. In the event thefloor controller detects any activity, the floor controller communicatesthat activity to a file server 32, which is connected to the floorcontrollers via a high speed network 38 connected therebetween.

In the preferred embodiment, the file server 32 includes a highperformance personal computer or work station having a large hard diskcapacity in order to store the gaming device activity therein. In thepreferred embodiment, the high speed network 38 is a ten megabyteethernet network. The system 10 also includes commercially availablenetwork software to support the industry-standard ethernet network 38.An example of such network software is Novell network software sold byNovell of Provo, Utah. The file server 32 also includes a databaseprogram by which reports can be generated using the data stored on thefile server. Such reports include, e.g. area, model, denomination andsummary reports. The database software also allows a user to generatecustom reports. The database software is based on the industry-standardParadox database language.

The system 10 also includes a pit terminal 34 which is also connected tothe ethernet network 38. The pit terminal 34 is also a standard personalcomputer, in the preferred embodiment, and can be used to monitor thegaming device activity in the pit. This terminal 34 can also be used asa security monitoring device to detect any unanticipated events likefills or payouts.

The system 10 further includes any number of fill and jackpot processingterminals 36. These terminals 36 are placed in the cage and/or thechange booth areas of the casino for fill and hand-paid jackpotprocessing. When a fill is required, a floor person goes to the nearestcashier's booth and states the gaming device number requiring a fill.The booth attendant enters the number into the fill and jackpotprocessing terminal 36 located in the cashier's booth. The terminal 36then looks up the record associated with the particular gaming device inthe file server 32 to determine the correct fill amount. The terminal 36also calculates a theoretical hopper balance for the particular devicebased on the latest meter information, as described further below. Ifthe calculation shows a significant hopper balance, a warning is givenon the computer screen from which security can then be alerted.

A fill and jackpot processing terminal 36 prints a fill ticket upondemand. If the calculated hopper balance was nearly zero, the terminal36 cause the words “computer verified” to be printed on the ticket inplace of a supervisor's signature. In the event that the calculatedhopper balance was not near zero, an extra signature is required tocomplete the fill transaction. The system follows a similar procedurefor processing hand-paid jackpots.

A dispatch station (not shown) can also be included in the system. Thedispatch station allows the casino to monitor activity on the gamingdevices and “run the casino” from one location. The dispatch stationallows the dispatcher to monitor customer service, maintenance, andsecurity events and direct other casino personnel to handle thesesituations appropriately. For example, during hopper empties (fills) andjackpot events, as indicated by the dispatcher station, the dispatchercould radio down to the floor to have someone verify the event. Thedispatcher station can also indicate when a machine door is openedwithout a technician card inserted, for example, in which case thedispatcher could take the appropriate course of action.

The above-described system 10 is but one embodiment of the systemaccording to the invention. The system tasks can be allocated in avariety of ways amongst the system computers including floor controllers18 and 28, file server 32, pit terminal 34 and fill and jackpotterminals 36. In some cases, the pit terminal 34 and fill and jackpotterminals 36 can even be eliminated and their tasks allocated to thefloor controller or file server. In fact, because the file server 32 isessentially a virtual hard disk for the floor controllers 18 and 32, thefloor controllers and the file server can be considered a single hostcomputer for the system 10.

B. Data Communication Node

1. Overview

In order to communicate with the floor controller, each gaming deviceincludes therein an electronic module 40, as shown in FIG. 2. Thismodule 40 can be inserted into a variety of pre-existing gaming devices.The module allows the host computer to uniquely identify the gamingdevice on the network, including the device type. The module 40 includestwo main subcomponents: a data communication node 42 and a playertracking module 44. The data communication node 42 keeps track of thecoins-in, coins-out, coins to drop, games played, jackpot occurrencesand other related functions of the associated gaming device. The playertracking module 44 keeps track of the player that is playing theassociated gaming device. Together, the data communication node 42 andthe player tracking module 44 allow the floor controller connected tothe associated gaming device to monitor and control the activity of thegaming device. The system hereinafter described in detail includes thefollowing capabilities: slot accounting, player tracking, bonus jackpotsand cashless play.

2. Controller and Memory

The data communication node (DCN) 42 includes a data communication nodecontroller 46, which in the preferred embodiment is an HD6473258P10controller manufactured by Hitachi of Tokyo, Japan. The DCN 42 iscoupled to the player tracking controller 44 through bus interface logic45. The bus interface logic 45 is conventional interface logicincluding, for example, transceivers, as is known in the art of digitaldesign.

A memory 48 is connected to the DCN controller 46. The memory includesprogram memory for storing program instructions for the DCN controller46. In the preferred embodiment, this program memory includes anonvolatile read-only memory (ROM). However, this program memory couldalso be flash or “battery”backed RAM in order for the program memory tobe updated by the floor controller. In the event flash or “battery” backRAM is used the floor controller would download the updated program tothe DCN controller and the DCN controller would overwrite the programmemory with the downloaded program.

The memory 48 also includes system memory, e.g., static random-accessmemory (SRAM) for storing the gaming device information. This gamingdevice information includes at least the following meters: coins-in,coins-out, coins to drop, games played, jackpot occurrences. A separatemeter counter is kept in memory 48 for each of these values. To increasereliability of the data, in the preferred embodiment, a redundant set ofthese counters is kept in a physically separate memory device withinmemory 48. Moreover, the memory devices storing these counters arenonvolatile so that in the event of a power failure the counts will beretained. The nonvolatile memories can either be battery-backed SRAM orelectrically erasable programmable read-only memory (EEPROM). Althoughmemory 48 is shown external to DCN controller 46, much if not all of thememory 48 can be included in the DCN controller 46.

3. Network Interface

The data communication node 42 also includes a network interface 49 forconnecting the data communication node 42 to the associated floorcontroller. The network interface is coupled to the floor controllerthrough a personality board 202, described below.

A more detailed drawing of network interface 49 is shown in FIG. 3. InFIG. 3, the DCN controller 46 receives data from the floor controllerover conductor 52 which is optically isolated from a connector 51 byoptical isolator circuit 54. The DCN controller 46 transmits data to thefloor controller over conductor 56, which is optically isolated from theconnector 51 by optical isolator circuit 58. Each of the opto-isolatorcircuits 54 and 58 include an opto-coupler as are known in the art. Abus 222 (FIG. 2) is connected between the network interface 49 and thepersonality board 202.

4. Serial Machine Interface

Referring to FIG. 2, the data communication node includes a serialmachine interface 60. The serial machine interface 60 allows the datacommunication node 42 to communicate with the associated gaming deviceadvance serial interface as contrasted with the discrete interface, tobe described further hereinafter. A bus 224 (FIG. 2) connects the serialmachine interface 60 to the associated gaming device at connector 62.The serial interface, in the preferred embodiment, is a standard RS-232three wire interface.

Referring to FIG. 3, the DCN controller 46 receives data from the gamingdevice over conductor 64 which is connected between the DCN controller46 and a differential to single-ended converter 66. The DCN controller46 transmits data to the gaming device over conductor 68 connectedbetween the DCN controller 46 and the converter 66. The converter 66converts the differential inputs of the serial interface 62 to asingle-ended output which is transmitted over conductor 64 to the DCNcontroller 46. The converter 66 also converts the single-ended inputreceived from the DCN controller 46 to a differential output signal andtransmits that to the serial interface 62. The serial machine interfaceis the means by which the DCN controller communicates certainreconfiguration data, referred to as reconfiguration commands, to themachine. These reconfiguration commands cause the machines to activate abonus payout table to allow the machine to append bonus payments totheir standard jackpot payouts, as specified by their payout table,during certain bonus activities.

5. Serial Display Interface

The data communication node 42 further includes a serial displayinterface 70 illustrated in more detail in FIG. 3. The serial displayinterface 70 includes logic coupled between the DCN controller 46 and anexpansion connector 71. The expansion connector 71 allows the DCNcontroller 46 to communicate with an expansion device connected thereto.

6. Discrete Machine Interface

The data communication node 42 also includes a discrete machineinterface 72, which is shown in detail in FIG. 4. The discrete machineinterface 72 includes a plurality of opto-couplers 78 coupled betweenthe discrete outputs from the gaming device or machine and the DCNcontroller 46. The discrete outputs of the machine are received atterminals 74A-74J of a connector 74 via a cable (not shown) connectedbetween the machine and the connector 74. The discrete outputs arecoupled to corresponding inputs 76A-76J via opto-couplers 78. Thediscrete outputs from the machine include: an EXTRA signal, a POWERsignal, a COIN IN signal, a COIN OUT signal, a COIN DROP signal, aJACKPOT signal, a HANDLE signal, a TILT signal, a SLOT DOOR signal, anda DROP DOOR signal. Each of these signals correspond to a known event inthe machine. For example, when a coin is dropped in the machine a COININ signal appears on terminal 74C. This COIN IN signal is thentransmitted to the DCN controller 46 on line 76C via the associatedopto-coupler.

All of the signal lines 76A-76J include a pullup resistor and a pulldowncapacitor, which combined form an RC network on the associated line. Theresistors are, in the preferred embodiment, in the form of a resistorpack 80 and the capacitors are individual discrete capacitors 82.Alternatively, the capacitors can be removed for high-speed signals.

7. Machine Configuration Circuit

The data communication node 42, as shown in FIGS. 2 and 3, furtherincludes a machine configuration circuit 84. In the preferredembodiment, as shown in FIG. 3, the machine configuration circuit 84includes a parallel to serial converter 86, which includes eightparallel inputs IN, a serial input SIN, a clock input CLK, a strobeinput STB, and a serial output SOUT. The parallel inputs IN areconnected to a personality board, as described hereinafter, to receive aunique machine configuration number therefrom, which uniquely identifiesthe type of machine that the data communication node is connected to. Inthe preferred embodiment, the machine identification number is comprisedof six bits. Therefore, the two remaining parallel inputs can be used toprovide additional inputs, such as additional discrete machine inputs,to the DCN controller 46.

The machine configuration number presented on the parallel inputs of theparallel to serial converter 86 is latched therein responsive to astrobe signal received at the strobe STB input. A strobe input isgenerated by the DCN controller 46 on conductor 90 which is coupled tothe strobe STB input. The parallel data is clocked out of the converter86 to the DCN controller 46 on conductor 88 and connected between theserial output SOUT of the converter 86 and an input of the DCNcontroller 46 responsive to a clock signal received on the clock inputCLK of the converter 86. The clock signal is generated by the DCNcontroller 46 and is transmitted to the converter 86 via conductor 92which is coupled between an output of the DCN controller 46 and theclock input CLK of the converter 86.

The converter 86 also includes a serial input SIN for receiving serialinput data. The serial input SIN is coupled to an expansion terminal 94Cof expansion connector 94. Conductors 90 and 92 are also coupled to theexpansion terminal 94 to provide the clock and strobe signals thereto.The expansion terminal 94 therefore provides the means for the DCNcontroller 46 to access additional serial information through theparallel to serial converter 86. In the preferred embodiment, theparallel to serial converter 86 is part number 4021 manufactured byToshiba Corporation of Tokyo, Japan.

C. Player Tracking Module

1. Overview

Referring again to FIG. 2, the module 40 coupled to each of the gamingdevices includes a player tracking module 44. The player tracking (PT)module 44 includes a player tracking controller 98, a card reader 100, aserial display driver 101, a display 102, and expansion interfaces 104and 106. The player tracking controller 98 communicates with the datacommunication node controller 46 through bus interface logic 110. TheDCN controller 46 and PT controller 98 maintain a master-slaverelationship, respectively. Therefore, all communication is initiated bythe DCN controller 46. The bus interface logic is conventional logic andits design is well-known in the art of digital electronics.

In the preferred embodiment, the player tracking module 44, with theexception of the card reader 100 and the display 102, resides on asingle printed circuit board, while the data communication node 42resides on a separate printed circuit board. The player tracking module44 and the data communication node 42 are then connected by a cable 111such as a ribbon cable.

2. Serial Display Circuit

A more detailed drawing of the player tracking module 44 is shown inFIG. 5. In FIG. 5, the serial display circuit 101 includes a transistorQ1 and a resistor R1 connected to the base thereof. A conductor 112 isconnected between the PT controller 98 and the resistor R1 to provide adrive signal to transistor Q1. The drive signal causes transistor Q1 toconduct a current and thereby drive a display connected to the collectorof Q1 at a terminal 114 of a connector 115. In the preferred embodiment,the terminal 114 is connectable to a small vacuum florescent display toprovide serial display data thereto.

3. Serial Expansion Ports

The player tracking module 44 also includes two serial expansion ports104 and 106. Each of the expansion ports 104 and 106 includes adifferential to single-ended converter 116 and 118, respectively. In thepreferred embodiment, these converters 116 and 118 are part numberLTC490 manufactured by Linear Technology Corporation of Milpitas, Calif.The PT controller 98 communicates with each converter via twosingle-ended, serial signal lines: an input signal line and an outputsignal line. The converters convert the single ended signals appearingon these lines to differential signals. The differential signals,however, can be used as single-ended signals as is known in the art. Thefirst expansion port 104 interfaces the player tracking node 44 with alarge vacuum florescent display 102 (FIG. 5) used to display playertracking messages, as described further below. The display is connectedto the connecter 115, in the preferred embodiment, by a cable 103. Theother expansion ports 106 provides the player tracking module withfuture expansion capabilities to support additional features.

4. Card Reader

Referring now to FIGS. 6 and 7, the card reader 100 will now bedescribed. FIG. 6 shows the electrical schematic for the card readerwhile FIG. 7 shows the mechanical drawing thereof. In FIG. 7A, anexploded view of the card reader is shown. The card reader includes aplastic bezel 116 having a card reader opening 118 formed therealong forreceiving a card 120 therein. The bezel 116 includes guide rails 122 and124 disposed at opposite, respective lateral ends of the opening 118.The guide rails 122 and 124 have stops 126 and 128, respectively. Theguide rails 122 and 124 guide the card 120 through the opening 118 untilan end of the card 120 contacts stops 126 and 128. The card is shownfully inserted in FIGS. 7B and 7C with the end of the card 120 abuttingthe stops 126, 128.

The card reader also includes a printed circuit board 130 having alongitudinal opening to allow the guide rails 122 and 124 to be insertedtherein in order to allow the printed circuit board 130 to be pushed upflush against a mounting plate 132 of the bezel 116, as shown in FIGS.7B and 7C. Mounted on one side of the printed circuit board 130 is anarray of photodiodes 134 and an array of photodetectors 136. Thephotodiodes 134 are mounted on the printed circuit board along one sideof the opening in the printed circuit board, while the photodetectors136 are mounted on the printed circuit board along an opposite side ofthe opening. The photodiodes and the photodetectors are verticallyaligned in a one-to-one relationship, i.e., one photodiode for eachphotodetector. In the preferred embodiment, the array of photodiodesincludes eight individual diodes spaced equidistance along the openingin the printed circuit board 130. The photodiodes 134 are mounted alongthe opening in the printed circuit board 130 so as to align withseparate rows of openings in the card 120, as described further below.The card reader also includes optional light masks 138 and 140. Thelight mask 138 is associated with the array of photodiodes 134 and has aplurality of openings therein, each opening corresponding to anindividual photodiode in the array 134. Similarly, light mask 140 isassociated with the array of photodetectors 136 and also has one openingfor each of the photodetectors. The light mask 138 is mounted on theprinted circuit board 130 beneath the array of photodiodes 134 along theopening in the printed circuit board 130. The light mask 138 is alignedwith the photodetectors 134 so that the openings in the light mask 138are directly beneath a corresponding photodiode in the array. The lightmask 138 minimizes the amount of light emitted by a photodiode that canbe detected by a photodetector other than the correspondingphotodetector. The light mask 140 is mounted on top of the photodetectorarray 136 so that the openings therein align with the individualphotodetectors. The light mask 140 further eliminates extraneous lightfrom the photodiodes as well as extraneous ambient light.

Also mounted on the printed circuit board 130 are a plurality oflight-emitting diodes 142, as shown in FIG. 7C in broken line. Thelight-emitting diodes are mounted on a side of the printed circuit boardopposite the side on which the photodiodes and photodetectors aremounted on. The light-emitting diodes 142 are mounted around theperimeter of the opening in the printed circuit board 130 and arereceived in a recessed portion 144 of the bezel 116. The light-emittingdiodes 142 comprise a means for providing visual feedback to a userinserting a card 120 into the bezel 116, as described further below. Inthe preferred embodiment, the light-emitting diodes 142 are duallight-emitting diodes capable of producing two primary colors and athird combination color.

Referring now to FIG. 6, an electrical schematic of the card reader isshown. The schematic includes the array of photodiodes 134 disposedalong one side of the card reader opening 118 and the array ofphotodetectors 136 disposed along the opposite side of the opening 118.In the preferred embodiment, there are eight photodiodes and eightcorresponding photodetectors. The photodiodes are arranged in pairs,with the two photodiodes within each pair being connected in a serialfashion. The anode of the first photodiode in the pair is coupled to thesupply voltage through resistor, while the cathode of a secondphotodiode in the pair is connected to an output of a driver circuit144. The driver circuit, in the preferred embodiment, includes two opencollector inverters connected in parallel. A signal is provided to thedriver circuit 144 by the PT controller 98 over a conductor 146. Asignal on conductor 146 causes the driver circuit 144 to conduct currentand thereby actuate the photodiodes 134 substantially simultaneously.

The photodetectors 136 are comprised of a plurality of light-sensitivephototransistors PD1-PD8. The emitters of the phototransistors PD1-PD8are all coupled to ground. The collectors of phototransistor PD1 and PD8are connected together and to a conductor 148 by which the PT controller98 senses light detected by either phototransistor PD1 or PD8.Phototransistors PD2 and PD7 are similarly connected with the collectorsof each being connected to a conductor 150. The collectors ofphototransistors PD3 and PD6 are also commonly connected to a conductor152. The collectors of the center phototransistors PD4 and PD5, however,are connected to separate conductors 156 and 154, respectively. Alsoconnected to each of the conductors 148-156 is a corresponding pullupresistor. In the preferred embodiment, the pullup resistors are includedin a resistor pack 158. Each of the conductors 148-156 are connected toa connector 170, which is coupled to the PT controller 98 as describedbelow.

Based on the above configuration of the phototransistors PD1 and PD8,only five conductors are required to sample all eight of thephototransistors. Without more information, however, the player trackingcontroller 98 would be unable to determine which of the twophototransistors commonly connected to a particular conductor, e.g.,conductor 148, detected light. For example, if either phototransistorPD1 or phototransistor PD8 detect light, the voltage level on conductor148 will drop from a high voltage of approximately 5 volts to a lowvoltage of approximately 0.7 volts. Without more information, the playertracking controller 98 would be unable to determine which of the twophototransistors, PD1 or PD8, actually sensed the light. According tothe invention, however, the card 120, as shown in FIG. 7A, includes afirst slot 150 by which the PT controller 98 can determine which of thetwo photodetectors detected the light, as described below.

The card 120 includes five rows of slots 152-160. The rows of slots152-160 are arranged in a matrix with the corresponding slot locationswithin each of the rows being aligned in columns. Only the first slot150 of row 152 cannot be aligned with any other slots, i.e., slot 150 isin a column all by itself. The individual slots within the rows of slots152-160 encode unique player tracking information. Each slot representsa single binary bit in the player tracking information. Either one oftwo conventions can be used to encode the information. First, a slot canrepresent a binary 1 and no slot can represent a binary 0. Second, aslot can represent a binary 0 and no slot can represent a binary 1. Theplayer tracking information can include: a unique player identificationnumber, the casino issuing the card, player membership information, etc.

In the preferred embodiment, the card includes five rows of slots eachhaving a maximum number of nine individual slots, thereby producing 45possible slots. The first row of slots 152, however, is not used toencode player tracking information, but instead is used to synchronizethe sampling of the player tracking information by the player trackingcontroller 98. Thus, only 36 slots are used to encode player trackinginformation in the preferred embodiment. This still allows 2ˆ³⁶ possiblecombinations, which is more than adequate.

The PT controller 98 uses the first row 152 to synchronize the samplingas follows. The PT controller 98 continuously samples the outputs of PD4and PD5 looking for a slot. If a slot is detected on either PD4 and PD5and no other slots are detected by any other phototransistors the PTcontroller 98 determines that the detected slot must be slot 150. The PTcontroller 98 then continuously samples the output of thephototransistor that detected slot 150. Once a new slot is detected bythat phototransistor, the PT controller 98 then samples the outputs ofthe other phototransistors, i.e., PD1-PD3 and PD6-PD8, on conductors148, 150 and 152 for slots in of the other rows. Thus, the PT controller98 synchronizes the sampling of the other rows of slots to the detectionof a slot in the first row 152.

It is important for the card reader to detect the orientation of thecard in order to correctly interpret the player identificationinformation encoded on the card. The card reader detects the orientationof the card 120 by detecting the slot 150. If slot 150 is detected byphototransistor PD4, then the card reader knows that the card is in theorientation shown in FIG. 7A. In that case, the card reader knows thatthe player tracking information is actually being detected onphototransistors PD5-PD8, and can interpret the player trackinginformation accordingly. If, however, phototransistor PD5 detects slot150, then the card reader knows that the card 120 is oriented 180degrees from that shown in FIG. 7A. In that case, the card reader knowsthat the player tracking information is being detected byphototransistors PD1-PD4, and can interpret the information accordingly.The PT controller 98 can simply transpose the player trackinginformation sensed on conductors 148-152 depending upon the detectedorientation of the card. Thus, the card reader according to theinvention is able to correctly interpret the player tracking informationregardless of how the player inserts the card 120 into the bezel 116 ofthe card reader. The invention is able to accomplish this with only fiveconductors between the eight phototransistors PD1-PD8 and the PTcontroller 98.

The card reader further includes a plurality of light-emitting diodes142 that are mounted on the printed circuit board 130 and received inthe recess 144 of the bezel 116, as shown in FIG. 7C. The LEDs 142 aremounted on the printed circuit board 130 so as to surround the cardreader opening 118 as shown in FIG. 6. In the preferred embodiment, thecard reader includes 24 dual diodes arranged in pairs. The dual diodeshave two separate diodes, each being able to emit a different primarycolor of light. In the preferred embodiment, the dual diodes emit eitherred or green light. The dual diodes can also emit a third combinationcolor if the two individual diodes in the dual diode are actuatedsimultaneously so that the two primary colors combine. In the preferredembodiment, this combination color is approximately orange due to thedifferences in the intensities of the red and green light.

The dual diodes are essentially treated as two individual diodes. Thered diodes R in the dual diodes are driven by a driver circuit 162,while the green diodes G in the dual diodes are driven by another drivercircuit 164. The driver circuits 162 and 164 are, in the preferredembodiment, two open collector drivers connected in parallel, as withdriver 145. However, other equivalent driver circuits would be apparentto those skilled in the art.

The dual diodes are arranged in pairs with the anodes of one of the dualdiodes being coupled to the supply voltage +5V and the cathodes of theother dual diode being connected to the output of the correspondingdriver circuit. Accordingly, the red diodes are commonly driven bydriver circuit 162, which is responsive to a signal received from the PTcontroller 98 on conductor 166. Similarly, the green diodes are commonlydriven by driver circuit 164, which is responsive to a signal receivedfrom the PT controller 98 on conductor 168. Therefore, the PT controller98 can selectively actuate the red diodes, the green diodes or both bygenerating the corresponding signals on conductors 166 and 168.

All of the conductors over which the PT controller communicates with thecard reader, i.e., 146-156 and 166-168, are connected to a connector 170as shown in FIGS. 6 and 7A. The player tracking module 44 then includesa cable 172 that is connected between the connector 170 and the PTcontroller 98, as shown in FIG. 5.

Although the preferred embodiment of the card reader is an optical cardreader, the invention is not limited to such. The lighted bezel can beused in conjunction with any form of card reader such as a magnetic cardreader, a bar code reader, etc. The method of providing visual feedbackto the player herein described is a general method which can be usedwith a plurality of cards and card readers.

5. Display

Referring now to FIG. 8, a schematic for the display circuit 102 of theplayer tracking module 44 is shown. The circuit 102 includes a displaycontroller 174, which in the preferred embodiment is a part numberHD6473258P10 manufactured by Hitachi of Tokyo, Japan. Coupled to thedisplay controller 174 is a memory 176 via bus 178. The memory 176, inthe preferred embodiment, is a 32 KB SRAM. The memory 176 stores thevariables and parameters necessary for the controller 174 to communicatewith both the PT controller 98 and the display driver 186. The bus 178includes the necessary address lines, data lines and control lines tointerface in memory 176.

In the preferred embodiment, the display 102 includes a vacuumfluorescent display (VFD) 184, which is organized as a 16×192 displaymatrix. Such displays are well-known in the art of digital electronics.The VFD 184 is driven by a driver circuit 186, which includes aplurality of individual drivers serially interconnected. In thepreferred embodiment, these serial drivers are part number UCN5818EPF-1,manufactured by Allegro Microsystems, Inc. of Worcester, Mass. Thedriver circuit 186 is connected to the VFD 184 by bus 188, whichincludes 160 individual conductors. The manner in which the 160 buslines are connected between the driver circuit 186 and the VFD 184 isknown in the art, and is therefore not described in detail herein.

The display controller 174 interfaces with the driver circuit 186 by aplurality of signal lines 190. These signal lines transmit the standarddriver interface signals to the driver circuit 186. These signalsinclude: a clock signal CLOCK, serial input data signal SDATA, a framesignal FRAME, a strobe signal STROBE, two output enable signals OE1/ andOE2/, a column clock signal COL CLOCK, and a column output enable signalCOL OE/. These signals have well known functions in the display art andare therefor not discussed in detail. The signal names having a “/”represent active low signals while all other signals are active high.The display controller 174 generates these signals in the requiredsequence in order to serially clock the reformatted display data to thedriver circuit. One of ordinary skill in the art could program thedisplay controller 176 to generate these signals in order to display thedesired message on the VFD 184 based on the foregoing description.

The display 102 also includes a serial interface 192. The serialinterface 192 is the means by which the PT controller 98 communicates aplayer tracking message to the display 102. In the preferred embodiment,the serial interface 192 includes two opto-isolator circuits: one forthe serial send data, the other for the serial transmission data. Thedisplay controller 174 is connected to the serial interface 192 over atwo conductor serial bus 194, one conductor for receiving serial datafrom the serial interface 192, the other for transmitting serial datathereto. A connector 196 is also coupled to the serial interface 192.The connector 196 includes four terminals. Two of the connectorterminals are dedicated to receiving serial input data and the other twoterminals are dedicated to transmitting serial data. A cable (not shown)couples the display 102 to the player tracking module 44 betweenconnectors 196 (FIG. 8) and connector 115 (FIG. 5).

6. Discrete Input Section

The display 102 further includes a discrete input section 198. Thediscrete input section 198 is an interface between the discrete outputsof a gaming device and the display controller 174 much in the same waythat the discrete machine interface 72 allows the data communicationnode to interface with a gaming device. Although in the preferredembodiment the discrete input section is unconnected to any discretemachine inputs, the discrete input section 198 allows the display 102 tooperate as a stand-alone module for gaming devices in certainconfigurations. The discrete input section provides discrete inputsignals from an external device to the display controller 174 over a bus200. The discrete input section 198 includes opto-isolator circuits suchas part number TLP620 manufactured by Toshiba Corporation of Tokyo,Japan which provide single-ended input signals to the display controller174.

D. Personality Board

Referring now to FIG. 9, a personality board 202 is shown in schematicform. The personality board 202 uniquely identifies the gaming device onthe network. The personality board 202 indicates the type of gamingdevice, e.g., slot machine or video poker, including the manufacturer,and provides a unique machine identification number that the hostcomputer can use to uniquely address the gaming device. The personalityboard 202 allows the devices to be readily removed and reinstalled inthe network without any manual reconfiguration by the operator, such asresetting dip switches.

The personality board 202 couples the data communication node 42 to agaming device. The personality board 202 includes two connectors 204 and206 and an identification circuit 208. The connector 204 couples to thedata communication node 42, as described further below. The connector206 connects to the particular gaming device. The components shown inFIG. 9 are mounted on a printed circuit board that is mounted inside aconnector harness (not shown). The personality board allows the DCN tobe easily removed and reinstalled from the network with minimal effort.

The personality board uniquely identifies the machine by providing botha configuration number, which indicates the type of gaming device thatis connected to the connector 206 and a unique identification number,which is used by the system 10 to maintain records on the machine. Theconfiguration number includes a six bit binary number which indicatesthe type of gaming device connected to the personality board 202. Eachmachine type is assigned a unique configuration number. Thisconfiguration number is encoded on lines CNFG0-CNFG5, which areconnected to terminals 204Q-204V, respectively, of connector 204. Eachline represents one bit of the binary configuration number. Theindividual lines are either tied to a supply voltage to represent abinary one or to ground to represent a binary zero. The six bitconfiguration number used in the preferred embodiment can encode up to2ˆ⁶ different combinations and, therefore, different machine types. Theconfiguration number for the embodiment shown in FIG. 9 is equal to 3CH.

The configuration lines CNFG0-CNFG5 are coupled to the inputs ofparallel to serial converter 86 (FIG. 3) through a connector (notshown). The terminals 204Q-204V of connector 204 have correspondingterminals 85Q-85V of connector 85, as indicated by correspondinglettered suffixes. This same lettering convention is used throughout.

The configuration number is used by the DCN controller 46 as a means ofinterpreting the discrete input signals received from the machinethrough connector 206. Individual conductors coupled between connector204 and 206 are labeled to correspond to the machine type having aconfiguration number 3CH. For a different machine type having adifferent configuration number, many of these conductors may havedifferent functions. By providing a unique configuration number, the DCNcontroller can interpret the signals received on these linesaccordingly.

The personality board 202 also includes an identification circuit 208which provides a unique machine identification number to the datacommunication node 42. The unique identification number is stored in anonvolatile memory 210 and provided to a terminal 204N on conductor ID.In the preferred embodiment, the nonvolatile memory 210 is a part numberDS2224 manufactured by Dallas Semiconductor of Dallas, Tex. In thepreferred embodiment, the nonvolatile memory 210 includes a 32 bit ROMhaving a factory-lasered unique serial number stored therein. Thisserial number, i.e., the machine identification number, can be read outof the memory 210 by the DCN controller 46 to uniquely identify themachine connected thereto. The protocol for reading the identificationnumber out of the memory 210, as is described in the data sheet for thepart, is well known in the art.

The identification circuit 208 includes a number of discrete components.The memory 210 has a zener diode 212 coupled across the power and groundterminals of 213 and 215 thereof. The identification circuit 202 alsoincludes a first diode 214 coupled between the power terminal 213 and adata output terminal 217. The circuit 208 further includes a seconddiode 216 coupled between the data output terminal 217 and the groundterminals 215. A resistor 218 is interposed between the data outputterminal 217 and the connector terminal 204N. The terminal 204N iscoupled to a corresponding terminal 74N of connector 74 (FIG. 4) by abus 220 (FIG. 2).

The discrete outputs from the machine, e.g., coin in, coin out, etc.,are also supplied to the data communication node 42 via bus 220. The bus220 connects connector 74 of the data communication node 42 and theconnector 204 of the personality board 202 such that terminals havingcorresponding lettered suffixes are connected. For example, terminal 74Cof connector 74 is connected to terminal 204C of connector 204 by aindividual conductor within bus 220. All the other terminals aresimilarly connected by the bus 220.

The network interface 49 of the data communication node 42 is alsocoupled to the personality board by a bus 222, as shown in FIG. 2. Bus222 includes four conductors which connects the four terminals ofconnector 51 with four corresponding terminals of connector 204, asindicated by the common lettered suffixes. It is over these four linesthat the DCN controller 46 indirectly communicates with the floorcontroller.

The serial machine interface 60 is also coupled to the personality board202 by a bus 224, as shown in FIG. 2. The bus 224 includes fourconductors which couple four terminals 62DD and 62EE of connector 62with corresponding terminals 204DD and 204EE, respectively. It is overthese four conductors that the DCN controller 46 communicatesreconfiguration commands to the machine. The DCN controller transmitsdata through the terminal 204DD, which is provided to the machine onconductor MACHINE RX. The machine responds to the configuration commandon the conductor MACHINE TX. The use of these two conductors will becomemore apparent in the description of the operation hereinbelow.

Although buses 220, 222, 224 and 226 have been described as separatebuses, the individual conductors within these buses could, and are inthe preferred embodiment, combined into a single bus that is connectedbetween the data collection node 42 and the personality board 202. Toconnect the data collection node 42 and the personality board 202 aconnector (not shown) is mounted on the data collection node 42 and amating connector (not shown) is mounted on the personality board 202.The two connectors are then mated together to connect the datacollection node 42 to the personality board 202. The personality boardis then coupled to the corresponding gaming device by a cable 225(FIG.2).

E. Bonus Display Drivers

Referring now to FIGS. 10 and 11, two bonus display drivers are shown.The data communication node 42 is designed to support either of thedisplay drivers. The data communication node 42 is coupled to thedisplay driver of FIG. 10 through connector 228. An opto coupler 230optically isolates the data communication node from a triac circuit 232which includes a triac 234. One terminal of the triac 234 is connectedto a terminal 236B of a connector 236. Another terminal of the triac 234is connected to a terminal 236C of connector 236. A bonus display suchas a light or sound generating means is coupled across terminals 236Band 236C so that the triac 234 could drive the external bonus displayresponsive to an actuation signal from the data communication node 42.

A second embodiment of the display driver is shown in FIG. II. In thisembodiment, the data communication node 42 is coupled to the drivercircuit through connector 238. The driver circuit of FIG. 11 includes arelay 240 operatively coupled to a transistor 242. The relay 240 is atwo-position relay which toggles between the two positions responsive toa current passing through transistor 242. The transistor 242 conducts acurrent responsive to an actuation signal received on terminal 238B fromthe data communication node 42.

The display drivers are used by the data communication node 42 toactivate a display on the gaming device which indicates that the machineis now in a bonus mode or condition.

F. Floor Controller

As shown in FIG. 1, the floor controller is directly connected to boththe high speed network 38 and a plurality of gaming devices. The floorcontroller is responsible for monitoring the activity of each of thegaming devices connected thereto and reporting this activity to thedatabase 32. In addition, the floor controller is responsible fortransmitting a reconfiguration command to a selected one or more of thegaming devices during certain bonus conditions. These conditions will bedescribed in detail in the operation section below.

The floor controller is connected to the associated gaming devices bycurrent loop networks. Because of the limitations of the current loopnetwork, only a predetermined number of gaming devices can be supportedon any one current loop network. In the preferred embodiment, eachcurrent loop network supports up to 64 gaming devices. In order for eachfloor controller to support more than this predetermined number ofgaming devices, each floor controller is equipped with a communicationboard 246, as shown in FIG. 12. The communication board 246 supports upto 16 separate current loop networks. The board is a standard size cardthat fits into one of the ISA card slots in the back of the floorcontroller. The board includes a male edge connector (not shown) whichmates with a female back plane connector (not shown) in the floorcontroller. The back plane connector provides the floor controller CPUdata, address, and control lines to the communication board 246 toenable the communication board and the floor controller CPU tocommunicate.

The communication board 246 includes eight separate microcontrollers248A-248H. The microcontrollers communicate with the floor controllerthrough ISA bus interface logic 247 over buses 249A and 249B. Themicrocontrollers are shown in a daisy-chain connection in FIG. 12, butany other equivalent interconnection scheme can be used. The datareceived from the floor controller microprocessor is passed between themicrocontrollers from 248A to 248H, as indicated by the arrows. Eachmicrocontroller is responsible for passing the data along anddetermining whether the data includes a message for a machine connectedto its corresponding current loop networks.

Each microcontroller is responsible for two current loop networks. Eachmicrocontroller communicates with its associated gaming devices via twocorresponding current loop networks. Two serial signal lines 251 connecteach microcontroller to a current loop driver circuit 250. The drivercircuit 250 provides the necessary current drive to support the currentloop network. Each pair of serial signal lines 251 has a correspondingpair of current loop lines 253. The current loop driver circuit 250 caneither be located on the communication board as shown in FIG. 12 or on aseparate printed circuit board (not shown). If located on a separateboard, the current loop driver circuit 250 can be connected to thecommunication board by a cable.

In the preferred embodiment, the last microcontroller 248H is solelyresponsible for communicating with the floor controller microprocessor.All of the data received from the machines over the various current loopnetworks are passed along to the microcontroller 248H by the associatedmicrocontroller. The microcontroller 248H analyses the data anddetermines whether the data needs to be communicated to the floorcontroller. If not, the last microcontroller records the communicationbut does not forward the data to the floor controller. This helpsoff-load some of the floor controller communication processing to thecommunication board.

II. Operation

The above-described system allows a casino in which the system isinstalled to run promotions on any properly equipped gaming machineswhile simultaneously gathering player tracking and accounting data fromall machines. The system provides the capability for the casino toselect which of the plurality of machines are used in any givenpromotion. The system further allows any number of different promotionsto operate simultaneously.

Each promotion involves sending a reconfiguration command from the floorcontroller to a gaming device that has been selected to be part of agiven promotion over the associated network. Upon receipt of thereconfiguration command, the gaming device reconfigures its payoutschedule in accordance with the received reconfiguration command. Asdescribed above, reconfiguring a gaming device payout schedule, in thepreferred embodiment, includes activating a bonus payout schedule thatpays out bonus amounts in addition to the amount determined by thedevice payout table.

A partial list of the promotions according to the invention include, butare not limited to: a multiple jackpot wherein the gaming devicereconfigures its payout to be a multiple of its default payout schedule;a bonus jackpot wherein the gaming device reconfigures its payoutschedule to payout an additional bonus amount when certain conditionsare met; and a progressive jackpot wherein two or more gaming devicesare combined in a progressive jackpot having a progressive jackpotpayout schedule. In addition to these, many other promotions arepossible by the above-described system for controlling and monitoring aplurality of gaming devices.

The system 10 also allows for improved player tracking. As with standardplayer tracking, the above-described system monitors and reports howmany coins are played by each player. The system 10, however, alsoincludes the ability to record how long each player spends at eachmachine and the number of coins won, games played, and hand jackpots wonby each player. All this information is stored on the database, whichcan be later analyzed for future targeted direct mailing campaigns. Theplayer tracking according to the invention also allows the casino toschedule buses and other groups and measure their profitability. Thesystem also allows for cashless play as well as advanced accounting andsecurity features.

Another feature of the above-described system is jackpot announcements.The jackpot announcement feature displays a message on a reader board ordisplay located in the casino which announces a jackpot as soon as ajackpot is won, i.e., as soon as the reels stop spinning. The floorcontroller generates the jackpot announcement once a DCN connectedthereto indicates a jackpot is won. An example of such a message mightbe: “Now paying on machine 1342, a jackpot of $300.” With prior art datacollection systems, the amount of the jackpot is only known after thepayment is made. Even then the system must account for partial pays,hopper empty, etc.

An advantage of the current system over prior art systems is the abilityto implement better tournament systems. In a slot tournament, playerspay a fee to play. All play during the session is free. The playersaccumulate credits instead of cash. The person with the most credits atthe end of the tournament wins. Games are usually manually altered toprovide payouts of 200 to 300% to make the games more fun. The games arealtered manually by replacing the read only memory (ROM) in the gamingdevices.

One exciting aspect of tournament play is to see who is ahead. Nocurrent system can display this information in real time. This isbecause current systems can only measure winnings as they are added tothe credit meter or paid from the hopper (some casinos use tournamenttokens instead). Since credits are usually added at a rate of 10 persecond, a 1,000 credit win can take 100 seconds to register. Casinosattempting to create display boards showing who is ahead are frustratedby the lag time. The jackpot announcement of the invention allowscasinos to display the player with the most credits by comparing thenumber of credits for each player. This comparison and display isperformed real time as each transaction is completed.

In order to implement each of these features, the various computers andmicrocontrollers each execute software or firmware. This software andfirmware routines are described below. These routines are described withreference to accompanying flow charts. These flow charts would enableone of ordinary skill in the art of computer programming to write acorresponding computer program which the computer or microcontrollercould execute.

A. Data Communication Node

1. Power Up Procedure

Referring now to FIG. 13, a power up procedure 252 for the datacommunication node is shown. This procedure is executed by the DCNcontroller 46 when initially powered up. The first step of the procedureis to validate the RAM to ensure that it is not corrupted and to set upall the DCN hardware. Validating the RAM involves writing known patternsof 1s and 0s to the DCN RAM. This RAM can either be internal to the DCNcontroller 42 or external as shown in FIG. 2. Setting up the DCNhardware includes initializing timers and interrupts.

Next the DCN controller checks the RAM in step 255 by reading thepattern of 1s and 0s back out of the RAM to ensure that the RAM is fullyfunctional. If the RAM turns out to be defective the DCN controller goesinto an endless loop in 256.

2. Reading Unique Identification Number

If the RAM is fully functional, the DCN then reads the uniqueidentification number from the personality board. As described above,this unique identification number is stored in a nonvolatile memory 210on the personality board. Reading the unique ID number out of thenonvolatile memory involves following the memory manufacturer'sinterface protocol as specified in the nonvolatile memory data sheet.The unique identification number provides a means for uniquelyidentifying the gaming device.

After the unique ID has been read from the personality board, the DCNprocesses the discrete machine inputs in step 260. This step will bedescribed in further detail in Subsection 3, MONITORING GAMING DEVICEDISCRETE INPUT below. After the discrete inputs have been processed instep 260, the DCN processes the machine serial interface in step 262.This step is described further below in Subsection 4, PROCESSING GAMINGDEVICE SERIAL INTERFACE. Next, the DCN processes the network interface,i.e., the interface between the DCN and the floor controller connectedthereto. The process network interface step 264 is described 3furtherbelow in Subsection 5, PROCESSING NETWORK INTERFACE. Finally, the DCNprocesses the player tracking interface in step 266. This step isdescribed below in Subsection 6, PROCESSING CARD INSERTION. At thecompletion of step 266 the DCN loops back to step 260 and continuously,sequentially executes steps 260-266.

3. Monitoring Gaming Device Discrete Input

Referring now to FIG. 14, the DCN step of monitoring the gaming devicediscrete inputs 260 will now be described. The DCN first reads thediscrete inputs on input lines 76 in step 267. One particular set ofdiscrete inputs is shown in FIGS. 4 and 9 for a particular gamingdevice. The actual discrete inputs present will depend on the machinetype, as indicated by the configuration number, which is also read bythe DCN controller 46. Most gaming devices provide at least some of thefollowing discrete inputs: coins in, coins out, coins to drop, gamesplayed, attendant paid jackpots, slot door, drop door, progressivejackpots, and bill validators. The system supports all of these discreteinputs as well as others.

The DCN keeps track of the machine activity by maintaining severalmeters in memory. Each meter, in the preferred embodiment, includes sixdigits. Moreover, to improve the reliability of the system, the DCNmaintains redundant backup copies of these meters with an order toreplace the original meters in the event that the originals arecorrupted. In step 268, the DCN increments the meters as required basedon the discrete inputs. The meters are maintained even in the event thatthe DCN is disconnected from the floor controller. Once the DCN isreconnected to the floor controller, all the activity level informationis then available. Step 268 will be discussed further below.

Next, the DCN processes the drop door signal in step 270. The drop doorsignal DROP DOOR indicates that the drop door on the machine has beenopened. This is an important event and is therefore processedseparately.

In step 272, the DCN validates the meter values to determine whether thevalues stored in the meters are valid. The DCN checks whether the metervalues are valid in step 274. In the preferred embodiment, a check sumis maintained for each meter value. Thus, the DCN in step 274 checks tosee whether the check sum is correct based on the current meter value.If the meter values are okay, the discrete input monitoring step 260 iscomplete. If the meter values are not valid, the DCN replaces the metervalues with the redundant back copy of the meter values in step 278, andthen the step 260 is complete.

Referring now to FIG. 15, increment meter step 268 is shown in furtherdetail. The sequence shown in FIG. 15 is repeated for each meter valuethat has changed. The first step is to adjust the meter value based onthe discrete inputs and to calculate the associated check sum. Next, theDCN determines whether the particular meter has an active associatedcountdown count in step 282. Some games or promotional activitiesrequire the player to reach a certain level of activity in order to beeligible for certain bonus points. These countdown counts are used todetermine whether the player has achieved this level of activity. Forexample, the player may be required to play a certain number of coinsbefore being awarded any points. If the countdown count is active, theDCN adjusts the current players count down values in step 284 based onthe corresponding adjustment of the associated meter.

In step 286, the DCN sets the current message to the count down message.The count down message indicates to the player when he or she will beeligible for the bonus points. Finally, in step 288 the DCN sets thecurrent bezel color and rate to a count down color and rate. This colorand rate information is subsequently transmitted to the player trackingnode for processing, as described further below. The countdown colorindicates the bezel color and the count down rate indicates thatflashing rate of the bezel color displayed during the count downmessage.

4. Processing Gaming Device Serial Interface

Referring now to FIG. 16, a process 262 for processing the gaming deviceserial interface is shown. The serial machine interface 60, as shown inFIG. 2, allows the DCN controller 46 to communicate with the gamingdevice through the personality board. This serial machine interfaceallows the DCN controller 46 to transmit reconfiguration commands to thegaming device in order to reconfigure the payout schedule of the machinein accordance with the reconfiguration command. In addition, the serialmachine interface provides an additional means for determining theactivity level of the gaming device. Instead of reading the discretemachine inputs, the DCN controller 46 can transmit a status requestcommand to the machine over the serial interface and the machine canrespond back with the requested status information.

Any communication protocol can be used to implement this communicationpath over the serial machine interface, as is known in the art. Anexample of one such protocol uses a data packet including a commandcode, a message sequence number, a CRC, and a variable length message.In the preferred embodiment, either the DCN controller 46 or the machinecan initiate communications over the serial machine interface. However,if the machine detects that the DCN is trying to send a message to themachine, the machine must abort its message and attempt to resend themessage at a later time.

The preferred embodiment of the system supports many differentreconfiguration commands. A partial list of the reconfiguration commandsis given below in Table 1. These reconfiguration commands are sent fromthe DCN controller 46 to the machine over the serial machine interfacewherein the machine reconfigures its payout schedule in accordance withthe particular reconfiguration command. The reconfiguration commands donot originate with the DCN, instead the reconfiguration commandsoriginate from the floor controller and are transmitted to a particularmachine over the associated current loop network or the command canoriginate at one of the other computers on the high speed network. TheDCN is simply responsible for forwarding the reconfiguration commandonto the gaming device on receipt of the reconfiguration command overthe associated current loop network coupled between the floor controllerand the DCN. TABLE 1 Examples of Reconfiguration Commands 1. Bonus PayFrom Hopper (Coin Format) 2. Bonus Pay to Credit Meter (Coin Format) 3.Bonus Pay from Hopper (Dollar Format) 4. Bonus Pay To Credit Meter(Dollar Format) 5. Add Non-cash outable credits to Game 6. Begin DoubleJackpot Time 7. Stop Double Jackpot Time

The actual process of processing the machine serial interface begins instep 292 wherein the DCN polls the machine to determine its level ofactivity. This polling step includes sending a status message from theDCN to the machine over the serial machine interface. In response, themachine will send a packet of status information indicating the currentamount of activity on the machine. The status information included inthe response will depend on the type of machine that the DCN iscommunication with.

The data communication node 42, in step 294, waits for a reply to thestatus request. If a reply is received, the DCN indicates that themachine is “on line” in step 296 and processes the machine reply in 298.The step of processing the machine reply includes updating the metervalues, as done when processing the discrete inputs. After the machinereply has been processed, the process 262 is complete.

If the DCN does not receive a reply from the machine in step 294, theDCN indicates that the machine is “off line”. The DCN will wait for apredetermined amount of time before deciding that the reply is notreceived. In the preferred embodiment, this predetermined period isapproximately 110 milliseconds.

5. Processing Network Interface

Another step in the DCN power up procedure 252 is the step of processingthe network interface 264. This step is described with reference toFIGS. 17-19. The network interface refers to the current loop thatconnects the particular DCN with the associated floor controller. Thefollowing description assumes that the DCN has received a valid messagefrom the associated floor controller. Because there are multiple DCNsconnected to any one current loop, the floor controller must includesome means for addressing a particular machine.

Although each machine includes a unique identification number whichcould be used as the actual address for each DCN on the current loop, itis unnecessary to use the unique identification as the actual addressbecause there are only a limited number of DCNs connected to eachcurrent loop. Accordingly, in the preferred embodiment of the invention,the floor controller uses a shorthand token representation of the DCN'sunique identification number to address the DCN. In the preferredembodiment, a single byte address is used to address a DCN on any givencurrent loop. This one-byte address allows up to 256 DCNs to besupported on any given current loop network. In the preferredembodiment, however, only 64 such DCNs are connected to a single currentloop and therefore the single byte address is more than adequate. Thesingle byte address substantially reduces the amount of traffic on thecurrent loop network by reducing the number of bytes from four in theunique identification number to one for the shorthand tokenrepresentation.

The floor controller is responsible for generating the unique singlebyte address for each data communication node on a given current loopnetwork. The process of assigning unique single byte addresses to theDCNs is described below in Section C.

Once all the DCNs have been assigned a unique address, the DCN can beginmonitoring the current loop network for messages addressed to it. If theDCN detects a message addressed to it, the DCN executes step 264. TheDCN first checks to see whether the message is valid in step 304. Thischeck is done by computing the CRC value of the message and comparing itto the CRC included with the message. If the two CRCs match, the messageis valid and the DCN processes the network message in step 306.Processing the network message is described further below with referenceto FIGS. 18 and 19. Once the message has been processed, the DCN sends areply back to the floor controller over the current loop network in step308. The actual substance of the reply will depend on the messagereceived in step 306. If the message is invalid, the DCN does not reply.

Referring now to FIG. 18, the first step of processing the networkmessage is to determine what type of message was sent from the floorcontroller in step 312. There are three basic types of messages that thefloor controller sends to the DCN. The first is a request for data fromthe DCN. If this type of message is detected the DCN builds the datarequested and transmits the data in a reply message. The main use ofthis message type is to gather status and meter information from theDCN.

Another type of message is one including configuration data for the DCN.This message allows the floor controller to implicitly set the DCN'smemory to a fixed value. This message is used to override the DCN'sinternal variables, e.g., to get a DCN out of a lock-up condition, or todownload new firmware to the DCN for execution. On receiving this typeof message, the DCN simply overwrites its memory with the configurationdata included in the configuration message in step 316. The DCN thenbuilds an appropriate acknowledgment and transmits this acknowledgmentmessage to the floor controller in step 320.

The other type of message is one sent in response to a DCN request. TheDCN processes this data in step 318, which is described further in FIG.19. If the message includes either the configuration data or the data inresponse to a DCN request, the DCN builds an acknowledge message in step320 and transmits this message to the floor controller.

The step of processing a floor controller message sent in response to aDCN request will now be described with reference to FIG. 19. The firststep of processing this type of message is for the DCN to determine whattype of data is included in the message. Once again there are threetypes of data that can be included in this message type: areconfiguration command, card data, or other minor data. The DCN makesthis determination in step 324 by analyzing one of the bytes in the datapacket of the message. This byte will be referred to herein as thecommand byte. If the command byte indicates that the message containsreconfiguration data, i.e., the command byte equals a reconfigurationcommand, the DCN stores the reconfiguration data in a predefined datastructure in memory. Listed below in Table 2 is an example of a datastructure for storing the reconfiguration data. TABLE 2 ReconfigurationData Structure 1. Bonus Type 2. Mystery Jackpot Data: A. Number of coinsto award B. Number of seconds to award C. Pay award to 3. Bonus TimeData A. Jackpot Multiplier B. Jackpot Payout Limitations C. Number ofSeconds to Keep Bonus Time Active D. Minimum Activity Level

The bonus type field of the data structure indicates the type of bonusstate the machine is to be placed in. Examples of potential bonus modesinclude progressive/nonprogressive, multiple jackpot, or mysteryjackpot. If the mystery jackpot is indicated, the mystery jackpot dataincluded in the structure specifies the conditions under which themystery jackpot is paid out. The mystery jackpot can be set to payout,e.g., after a certain number of coins in, handle pulls, which isspecified by subfields of the mystery jackpot data.

The bonus time jackpot is a promotion wherein the machine pays out morethan that dictated by its default payout schedule. In one embodiment ofthe bonus time promotion, the payout schedule of the machine can bemodified to be a multiple of its default to payout schedule, asspecified in subfield (A) of the bonus time data. This promotion can beused to encourage gaming activity during off-peak hours, e.g., midnightto 4 a.m. on weeknights. Alternatively, the bonus time promotion can beactivated on a random basis. The timing of the multiple jackpot isspecified by the casino on one of the computers connected to thenetwork. The bonus time data also specifies the conditions under whichthe player becomes eligible for the bonus time jackpot. The subfield (B)of the bonus time data specifies whether the player is eligible for thebonus time data only if the player is playing the maximum coin in themachine. Subfield (C) limits the bonus time promotion to a predeterminednumber of seconds. This field limits the bonus time promotion to apredetermined number of seconds; if the player does not hit a jackpotwithin this specified time period, the bonus time promotion concludes.The minimum activity level can also be specified in subfield (D). Thisfield can be used to specify the minimum activity level required by theplayer in order to be eligible for the bonus time jackpot. For example,the player can be required to play at least 20 coins over the last threeminutes in order to be eligible for the bonus time jackpot. An indicatorlight on the player's machine can be used to indicate when the playerreaches the minimum activity level and thereby becomes eligible for thebonus time jackpot.

In another embodiment of the bonus time promotion, a bonus amount isawarded in addition to the payout according to the default of the payoutschedule of the machine. The amount of the bonus jackpot is specified insubfield (E) of the bonus time data. For example, this bonus timepromotion might include five bonus amounts of $10, $25, $50, $100 and$500, which is specified by subfield (E). When a player hits aparticular jackpot, whichever bonus amount is specified by the bonusamount subfield this amount is automatically paid out in addition to thepayout amount determined by the machine's default payout schedule. Thisbonus time promotion can also be used in combination with subfields (C)and (D) to specify the conditions under which the player is eligible forthis bonus time jackpot award.

After the DCN has stored the reconfiguration data in step 326, the DCNwill then send the appropriate reconfiguration command to the machineover the serial machine interface in step 328. The machine, responsiveto the received reconfiguration command, reconfigures its payoutschedule in accordance with the received reconfiguration command. Forexample, if the reconfiguration command specifies a multiple jackpotcondition, the machine will reconfigure its payout to be a multiple ofits default payout schedule. The machine will reconfigure its payoutschedule in a similar manner for the other bonus types.

The other type of data that can be included in a response from a DCNrequest is card data or player tracking data. This data is sent to theDCN in response to a status message from the DCN to the floor controllerwherein the status message indicates that a player card has beeninserted. Included in this message is the card ID number detected by thecard reader. In response to this status message the floor controllerwill transmit a card insertion message to the DCN. The card insertionmessage includes information associated with the particular player IDnumber. An exemplary card insertion message data packet is listed belowin Table 3. TABLE 3 Card Insertion Message Data Packet 1. CardIdentification Number 2. Player First Name 3. Player Last Name 4.Current Point Balance 5. Casino Code

Upon receipt of the card insertion message, the DCN stores the player'sname and points in order for this information to be displayed on the VFDdisplay associated with the player tracking node. Then, a DCN sets thecurrent message to a data received message in step 334. Finally, a DCNsets the current bezel color and bezel rate to a data received bezelcolor and bezel rate in step 336. The bezel color specifies the bezelcolor to be displayed by the card reader and the bezel rate specifiesthe flashing rate of the card reader LEDs. This bezel information issubsequently transmitted to the player tracking node for processingthereby.

The final data type that can be included in the message sent from thefloor controller in response to a DCN request is generically classifiedas other minor data. This data includes general system or DCN specificinformation such as display information.

6. Processing Player Tracking Interface

The next step in the DCN process is processing of the player trackinginterface 266. The DCN maintains a variable that indicates what messageis to be sent to the player tracking node. This variable is referred toas the current message variable. Before transmitting a message to theplayer tracking node, the DCN first checks this variable to see which ofa plurality of messages should be sent to the player tracking node.

The process 266 begins in 340 by sending the current message to theplayer tracking node that is specified by the current message variable.In addition to the current message, the DCN sends the bezel color andbezel rate information to the player tracking node. The bezel color andbezel rate information could have been specified by the floor controlleror by the DCN itself.

Next, the DCN determines the card status in step 342. If there is nocard inserted in the card reader, the DCN sets the current messagevariable to an attract message. This message specifies that the playertracking node is to display a message which will attract players to themachine. Similarly, the DCN sets the current bezel color and bezel rateto an attract bezel color and rate in step 346. This attract color andrate is part of the attract message that will be sent to the playertracking node when the current message is sent.

If the DCN determines that a good card has been inserted in the cardreader, the DCN processes the valid card in step 350. This step isdescribed further below with reference to FIG. 21.

If, however, the card status indicates that a bad card has beeninserted, i.e., an invalid card number, the DCN sets the current messagevariable to specify a card error message in 352 and the DCN sets thecurrent bezel color and bezel rate to a card error color and rate in354. This card error information is included with the card error messagethat is sent to the player tracking node when the current message issent.

7. Processing Card Insertion

Referring now to FIG. 21, the process 350 for processing a valid cardinsertion is shown. The first step that the DCN executes is to determinewhether the card data corresponding to the valid card has been receivedfrom the floor controller in step 356. If not, the DCN builds a networkrequest message for the player name and points associated with the cardID number in step 358. Next, the DCN sets the current message variableto specify a card inserted message is to be transmitted in step 360.Finally, the DCN sets the current bezel color and rate to a cardinserted color and rate, which indicates to the player that the systemis still processing the card number. This information is sent to theplayer tracking node when the current message is sent.

If the card data has been received from the floor controller, the DCNthen determines in step 366 whether player tracking has started for theparticular player. If player tracking has not yet started, the DCN setsthe current message variable to the data received message in step 368and sets the current bezel color and rate to data received color andrate in step 370. If player tracking has started, the DCN processes theplayer tracking in step 372, as described with reference to FIG. 22.

Processing player tracking 372 begins with the step of determiningwhether the player has received new points in 374. These points can beconsidered roughly as the equivalent of “frequent flyer miles” used byairlines. These points allow the system to run promotionals wherebyindividuals are given points or credit associated with their card thatcan be redeemed toward the purchase of goods or services offered by thecasino. Typically these points are redeemed at a redemption counter inthe casino for meals or clothing, for example. The points, therefore,are an additional inducement to encourage play.

The player tracking system of the invention allows the casino todetermine how and when the player is issued points. The casino canspecify the type and number of coins that must be played before a playeris awarded a given number of points. The system uses this specifiedinformation to inform the player of his or her progress towardsreceiving additional points. The system encourages play by informing theplayer of how many additional coins must be played before receivingadditional points. For example, a player who is only one coin away fromreceiving points, but who desires to stop playing, may decide to play“one last coin” in order to receive the points. The system informs theplayer by displaying a message on the vacuum florescent displayindicating how many coins the player is away from receiving additionalpoints.

Referring now to FIG. 22, player tracking 372 begins with the step ofdetermining whether the player has received new points in 374. If no newpoints have been received, the DCN sets the current message variable tospecify a countdown message in step 376 and sets the current bezel colorand bezel rate to a countdown bezel color and rate in step 378. Thecountdown bezel color and rate indicates the player's progress towardsbeing awarded additional points.

If new points have been received, such as where the player has played agiven number of coins, the DCN sets the current message variable to apoints won message in step 382 and sets the current bezel color and rateto a points won color and rate in step 384. The points won messageinforms the player of the number of points won.

The above-described tracking process provides a means for providingvisual feedback to the player inserting the card into the card reader.By modifying the bezel color and bezel rate, the data communication nodeprovides immediate feedback to the player concerning the properinsertion of the card. If the player inserts the card properly into thecard reader so that the card reader senses a valid user identificationnumber, the card reader provides positive visual feedback to the user byilluminating the bezel. On the other hand, if the user improperlyinserts the card so that the card reader cannot read the useridentification number, the card reader can provide negative visualfeedback to the player by illuminating the bezel with a different colorand/or flashing rate. In the preferred embodiment, this positive visualfeedback includes flashing the green LEDs to produce a flashing greensignal around the card reader opening. The negative visual feedbackincludes flashing the red LEDs. A third combination color is used duringthe processing of the player tracking information. This process providesimmediate feedback to the player concerning the insertion of the card inthe card reader.

B. Player Tracking Module

The system described above allows for improved player tracking byrecording each and every machine transaction including: time of play,machine number, duration of play, coins in, coins out, hand paidjackpots and games played. The player tracking is conducted over thesame network as the accounting data is extracted. This allows theinvention to provide bonusing to certain individual players as well asduring certain times. As with standard player tracking, theabove-described system monitors and reports how many coins are played byeach player. The system according to the invention, however, alsoincludes the ability to record how long each player spends at eachmachine and the number of coins won, games played, and hand jackpots wonby each player. The system is able to record all this informationbecause the it operates on a transaction by transaction basis. Eachtransaction, whether it be a coin in, a handle pull, etc., is recordedby the system. Other prior art systems simply compile the playertracking information at the completion of play.

All the transaction information is stored on the database, which can belater analyzed for future targeted direct mailing campaigns. The playertracking according to the invention allows the casino to schedule busesand other groups and measure their profitability. Because the systemrecords each transaction, the casino can reconfigure their casinos tobetter match the tastes and demands of their customers.

The improved player tracking according to the invention also allows thecasino to calculate theoretical wins exactly because the system alwaysincludes the most current information. The operation of the playertracking procedure is described below.

1. Power Up Procedure

The operation of the player tracking module will now be described withreference to FIG. 23 where the powerup process 400 for the playertracking node is shown. As in the data communication node, the playertracking node first validates the RAM and sets up its associatedhardware in step 402. Next, the player tracking node tests the RAM instep 404 to determine whether the RAM is functioning properly. If not,the player tracking node, i.e., player tracking controller, terminatesits program in an error condition in step 406. If the player trackingRAM is fully functional, the player tracking node sequentially executessteps 408-414. In step 408 the player tracking controller processes theDCN interface between the player tracking controller and the DCNcontroller. In step 410 the player tracking controller updates theplayer tracking display. In step 412 the player tracking controllerupdates the bezel. Finally, the player tracking controller processes thecard reader in step 414. Each of these steps will now be describedfurther below.

2. Processing DCN Interface

Referring now to FIG. 24, the steps for processing the DCN interface areshown. First, the player tracking controller checks for a new messagereceived from the DCN in step 416. If a new message has been received,the player tracking controller overwrites its current message bufferwith the new message and updates the bezel color and rate values withthose contained in the new current message. Then, the player trackingcontroller builds a card status reply message in step 420. The cardstatus message indicates whether a card has been inserted and if sowhether the card was a good card or a bad card, i.e., the card was readproperly by the card reader. If a valid card, the card status replymessage also includes the identification number encoded on the card.This step might also involve transposing the number encoded on the carddepending on the orientation in which the card was inserted into thecard reader. This card status reply message in then sent to the DCN instep 422.

3. Processing Display Update

The process of updating the player tracking display is shown in FIG. 25at 410. This process begins with the player tracking controller scanningthe display message for display attribute information. Examples of suchdisplay attribute information is given below in Table 4. Each displayattribute specifies a different graphic mode for the player trackingdisplay. TABLE 4 DISPLAY ATTRIBUTE INFORMATION 1. Flash Rate 2. CenterDisplay 3. Set Display Intensity 4. Use Small Lower Font 5. Use SmallUpper Font 6. Use Normal Large Font 7. Set Pause Time 8. Set ScrollSpeed 9. Center and Melt 10. Center and Scroll Down 11. Center andScroll Up 12. Scroll Down and Stop 13. Scroll UP and Stop 14. ScrollLeft and Stop and End of Message 15. Scroll Down 16. Scroll Up 17.Scroll Right 18. Scroll Left 19. Reverse Video 20. Normal

The player tracking controller then determines whether any suchattribute information is found in the display message. If so, the playertracking controller sets up the display driver to incorporate thegraphics mode specified by the attribute information. The playertracking controller then strips out any display attribute informationfrom the display message in step 432 because the display attributeinformation is embedded in the display message. The remaining data inthe display message is the actual text to be displayed by the playertracking display, e.g., the player's name. The player trackingcontroller then sends this text to the display in step 434, which isthen displayed by the player tracking display.

4. Processing Bezel Update

The player tracking node is also responsible for updating the bezel,both in terms of its color and flashing rate. This process 412 is shownin FIG. 26. The first step in processing the bezel update is todetermine to bezel color as specified by the DCN and then drive theappropriate LEDs in the card reader. As described above, the preferredembodiment of the card reader includes dual diodes having two primarycolored diodes that can be driven separately or in combination toproduce three different colors.

Next, the process determines the bezel rate as specified by the DCN. Ina first case, the bezel rate is zero or off and thus the player trackingcontroller turns the LEDs off in step 442 in this case. If the bezelrate specifies a flashing rate, the player tracking controller flashesthe bezel at the appropriate bezel rate in step 442. Flashing the bezelinvolves turning the LEDs on and off at the specified rate. This can beaccomplished by a timer interrupt or a timing loop executed by theplayer tracking controller. The final option is that the rate can beinfinite or effectively a solid bezel color. In this case, the playertracking controller simply leaves the card reader LEDs on in step 446.This completes the processing bezel update process 412.

5. Processing Card Reader

The next process step for the player tracking node is to process thecard reader. This process 414 is shown in FIG. 27. The first step is forthe player tracking controller to determine the card status in 450. Inthe preferred embodiment, the card status is determined by comparing thechecksum of the card, as read off the card by the card reader, to acomputed checksum of the data read off the card. Other methods ofdetermining card status can be used as well depending on the type ofcard reader employed.

If the player tracking controller determines that a valid card wasinserted in the card reader, the player tracking controller sets a cardstatus variable equal to good card. This card status is thensubsequently transmitted to the DCN controller. Then, the playertracking controller sets a card ID variable equal to the identificationnumber read by the card reader in step 454. The card status and the cardID provide the DCN with sufficient information to instigate the playertracking.

If, on the other hand, the card reader indicates that the card was readimproperly or that the card is an invalid card for the card reader, theplayer tracking controller sets the card status variable to bad card instep 458 and the card ID variable is cleared in step 460. If neither avalid or invalid card condition was detected in 450, the player trackingcontroller sets the card status variable to no card in step 462 andclears out the card ID in 460.

C. Floor Controller

1. Power Up Procedure

Referring now to FIGS. 28-32, the process 464 operable on the floorcontroller will now be described. The process 464 is shown in FIGS.28-32 in flow chart forms. These flow charts would enable one ofordinary skill in the art to implement the process in computer softwareusing an appropriate computer programming language.

The floor controller process 464 begins at step 466 by opening thedatabase tables in the file server. As described above, the file serverincludes a commercially-available database program which stores themachine activity information as well as player tracking information andassociated system characteristic parameters. This step 466 can alsoinclude fetching some or all of these system characteristics in order totrigger certain events such as bonus jackpots, as described below.

In step 468, the floor controller terminates any active player trackingsessions in the database. Because player tracking may have been inprogress when the floor controller became inoperable, when the floorcontroller powers up or becomes operable, there may be player trackingsessions initially active. In this step, the floor controller terminatesany such active player tracking sessions in order to place the databasein an initial state.

Another step that the floor controller executes after becoming operableis to place an initial machine search message in an output message queue470. This search message is used by the floor controller to determinewhich machines are connected to the floor controller. This outputmessage is subsequently transmitted to all of the machines coupled tothe floor controller using a global message format, as described belowwith reference to FIG. 31. In the preferred embodiment of the invention,the message handling is through the use of message queues. Furthermore,the preferred embodiment is both an output queue for outgoing messagesfrom the floor controller to the machines and an input message queue formessages coming from the machines to the floor controller. Queues arewell-known data structures in the art of computer science and aretherefore not further discussed herein. Alternatively, themessage-handling could be done without the use of the queues. In such anembodiment the outgoing messages would be sent immediately rather thanbeing queued, and any incoming messages would be processed immediately.

The bulk of the work performed by the file server process 464 isperformed in message processing step 472. In this step, the floorcontroller processes all messages sent to or received from the machinesconnected thereto. This step will be described further below withreferences to FIGS. 29 through 31.

The process 464 also includes a system monitoring step 474. This systemmonitoring step 474 administers certain system-wide events. Thesesystem-wide events include the counting-related events and bonusingevents. The floor controller continuously checks to see whether any ofthese events have been triggered. If any event has been triggered, suchas a bonusing event, the floor controller takes the appropriate actionto handle the event. The event may be triggered by the time and day orby user intervention or other event. The system monitoring step 474 willbe described further below with reference to FIGS. 32 and 33.

The final step in process 464 is for the floor controller to check for atermination condition in step 476. In the preferred embodiment, thefloor controller checks to determine whether an ESCape key as pressed.If an ESC key was pressed, the floor controller terminates the process464. If no ESC key was pressed, the floor controller loops back to step472 wherein the message-processing step and the system monitoring stepare repeated. The floor controller continues in the loop 472-476 untilthe termination condition is sensed.

2. Message Processing

As described above, the floor controller acts as a gateway between themachines connected thereto and the file server, as shown in FIG. 1. Thefloor controller is responsible for forwarding the machine activityreceived from the various machines to the database. The floor controlleraccomplishes this communication through the use of messages. The messageprocessing step 472 is shown in more detail in FIG. 29.

The first step in processing the messages is for the floor controller tosend any messages that are queued-up in the output message queue to theappropriate data communication node in step 480. As described above, theoutput message queue is a simple data structure that is used to storeany pending messages. Included in the message is a destination addressby which the floor controller can determine which of the plurality ofdata communication nodes to send the message to. Next the floorcontroller receives any incoming messages from the data communicationnodes coupled to the floor controller in step 482. Once an incomingmessage has been received, the floor controller parses through themessage data included in the incoming message in steps 484 through 486.In the preferred embodiment, the floor controller parses through themessage data one byte at a time. Thus, in step 484 the floor controllerreads the next byte in the incoming message, and in step 486 the floorcontroller checks to see whether this is the last byte in the message.In the preferred embodiment, the message includes a message length fieldwhich indicates the number of data bytes included in the message. Inthis case, a floor controller in step 486 checks to see whether thenumber of bytes read in step 484 is equal to the number of bytesspecified by the message length field.

Once the input message data has been parsed out of the incoming message,the floor controller takes the appropriate match in response to themessage data in step 488. This step is described further below withreference to FIGS. 30 and 31. Following the message-handling step 488,the floor controller checks in step 490 to determine whether anyresponse is pending. The floor controller makes this determination bychecking a transactions-in-progress structure which indicates whetherthe floor controller needs to respond to any previous message. If aresponse is pending, the floor controller queues up an appropriateoutgoing message in the output message queue in step 492. Otherwise, thefloor controller completes the message processing step 472.

Referring now to FIG. 30, the message-handling step 488 is shown in moredetail. The message-handling step begins by verifying that the messagedata corresponds to a valid message in step 496. In the preferredembodiment, the message includes a cyclical redundancy check (CRC) bywhich the floor controller can determine whether the message is valid orcorrupt. Only if the message is valid will the floor controller performany additional message-handling steps. The floor controller also parsesthrough the message in step 496 to determine what type the message is.The message type determines the appropriate floor controller action. Inthe preferred embodiment, the messages include a command code whichindicates the type of message.

The first type of message can be one which includes new meterinformation. The floor controller checks in step 498 to determinewhether the message includes this type of information. If the messageincludes new meter information, the floor controller saves the new meterinformation locally in step 500. The floor controller maintains localcopies of the meter information in order to minimize the amount oftraffic on the high-speed network. Because the machine meters change sorapidly, forwarding this new meter information on to the file servereach time one of these meters is altered would produce an excessiveamount of network traffic on the high-speed network. Therefore, in thepreferred embodiment, the floor controller saves this new meterinformation locally in step 500 and only forwards the new information onto the file server after a predetermined amount of time has elapsed.

Another type of message is one which requests data. The floor controllerchecks in step 502 to determine whether the message type is onerequesting data. Typically, these data requests will be for playertracking information such as where a player inserts a card into a cardreader whereupon the data communication associated therewith sends theidentification number encoded on the card to the floor controllerrequesting the player tracking data associated with the playeridentification number. If the floor controller detects a data request instep 502, the floor controller looks up the requested data in thedatabase on the file server in step 504. Also, in step 504, the floorcontroller marks a response pending in the transactions in progressstructure to indicate that this requested data needs to be sent back tothe DCN. As described above, the floor controller queues up outgoingmessages responsive to the transactions in progress structure.

Another message type is one used by the floor controller to establishnew machine addresses. The floor controller periodically checks todetermine whether any new DCN has been coupled to its associated currentloop networks in order to assign a unique address to that machine. Instep 506, the floor controller checks to see whether the incomingmessage is in response to such a process. If the incoming message is inresponse to a machine search, the floor controller assigns a new machineaddress to the responding machine in step 508. The entire process ofassigning new machine addresses is described below with reference toFIG. 31.

Finally, the floor controller in step 510 handles any miscellaneousmessages. These miscellaneous messages are used primarily for debuggingand trouble-shooting the machines.

3. Assigning Gaming Device Addresses

As described above, in the preferred embodiment of the invention, thefloor controller uses a shorthand token representation of the DCN'sunique identification number to address the DCN. In the preferredembodiment, a single byte address is used to address a DCN on any givencurrent loop. This one-byte address allows up to 256 DCNs to besupported on any given current loop network. In the preferredembodiment, only 64 such DCNs are connected to a single current loopnetwork and therefore the single byte address is more than adequate. Thesingle byte address substantially reduces the amount of traffic on thecurrent loop network by reducing the number of bytes from four in theunique identification number to one for the shorthand tokenrepresentation.

The floor controller is responsible for generating the unique singlebyte address for each data communication node on a given current loopnetwork. The process 508 of assigning unique addresses to the DCNs onthe current loop network is shown in FIG. 31. The process begins bydefining a range of unique identification numbers in step 512. Initiallythis will be a large range.

Next, the floor controller sends out a message to all of the DCNs on thecurrent loop network in step 514. The floor controller communicates withthe DCNs by using a standard communication protocol. In the preferredembodiment, this protocol defines a message format including adestination ID, a source ID, a message length, a data packet and a CRC.Other message formats could be used as well. Using this format, thefloor controller can communicate with all of the DCNs on the currentloop network by using a global destination address in the message. Thisglobal destination address would indicate to the DCNs that this messageis intended for all DCNs on the current loop network. This globalmessage would include two unique identification numbers that, takentogether, define the range of unique identification numbers establishedin step 512.

The individual DCNs then checks to see whether their uniqueidentification number falls within this range. If a DCN's uniqueidentification number falls within this range and the DCN does not havean address assigned thereto, the DCN then responds to this globalmessage by sending a reply message in response that includes the uniqueidentification number of that DCN. In the event that more than one DCNhas a unique identification number that falls within this range anetwork collision will occur and the message will be corrupted. Theprocess 508 checks for this condition in step 516. This condition isindicated by an invalid CRC in the message.

In the event of a network collision, the floor controller can limit therange of unique identification numbers by repeating step 512 in the hopeof eliminating this network contention.

If the response has a valid CRC, the floor controller assigns a uniqueaddress to the responding DCN, as identified by the uniqueidentification number in the response, in step 518. The floor controllerthen transmits this address along with the corresponding uniqueidentification number in an assignment message to all of the DCNs usinga global destination address in step 520. The DCNs then process thismessage and in the event that the unique identification number includedin the message corresponds to the DCN's unique identification number,the DCN adopts the address included in the message. Once the DCN hasbeen assigned an address in this manner, the DCN will interpret allsubsequent messages having a destination address equal to the assignedDCN address as being directed to that DCN. The above-described addressassignment sequence is repeated for each of the remaining DCNs on thecurrent loop network in step 522. The floor controller continues thisprocess until the entire range of unique identification numbers has beencovered and no more network collisions occur.

4. System Monitoring

Referring now to FIG. 32, the system monitoring step 474 will now bedescribed. The floor controller is now responsible for monitoringcertain system-wide conditions to determine whether certain events needto occur. The system monitoring step also handles request for particularmachine information. Thus, in step 524, the floor controller determineswhether a new request has been placed in the data base for suchparticular machine information. If such a request has been placed, thefloor controller responds to the special request for data in step 526 bysending a message to the particular machine requesting the requiredinformation. Once the required information has been received, the floorcontroller processes this information accordingly.

The floor controller also monitors the locally-stored meter informationin step 528. If the locally-stored information is changed, the floorcontroller saves the latest information to the data base in step 530. Asdescribed above, the floor controller saves the meter informationlocally in order to minimize the traffic to the file server over thehigh speed network.

The floor controller also monitors the system for certain event triggersin step 532. These triggers can be stored in the data base and fetchedby the floor controller during its power-up procedures. These triggersindicate if and when certain events occur. Examples of event triggersinclude: the drop period, the end-of-day, the bonus period, etc. If anevent trigger has occurred, the floor controller handles the event instep 534.

The handle event step 534 is shown in more detail in FIG. 33. The eventscan basically be bifurcated into accounting events and bonusing events.Accounting events refer to the data communication activity of thesystem. The accounting events are typically triggered by a certain timeof day such as the end of day or the drop period. If an accounting eventhas been triggered, the floor controller performs the required data baseoperations in step 538. This step involves updating all of thelocally-stored meter information and storing the updated meterinformation into the data base.

The other type of event can be referred to as a bonusing event. Thefloor controller checks to see whether the event is a bonusing event instep 540. The bonusing events can also be triggered by the time of day.For example, the bonusing event may be triggered from midnight to 4:00a.m. on weekdays. These bonusing periods can be specified in the database. If the triggered event is a bonusing event, the floor controllerinserts a corresponding reconfiguration message in the output messagequeue in step 542. The reconfiguration message includes areconfiguration command that is sent to an appropriate machine. Themachine, upon receiving the reconfiguration command, reconfigures itspayout schedule in accordance with the received reconfiguration command.According to the invention, there are many different reconfigurationcommands to implement a multiplicity of different bonusing events. Onereconfiguration command specifies that the machine should reconfigureits payout schedule to be a multiple of its default payout schedule.This reconfiguration command can also specify that the multiple payoutschedule should be limited to a predetermined percentage of the coinsin. This reconfiguration command can further specify that the multiplepayout schedule should be limited to only when the maximum coins areplayed. This reconfiguration command can further specify that themultiple payout schedule should be limited to payouts in a specifiedrange. This reconfiguration command can also specify the multiple payoutschedule should payout only when a predetermined level of playeractivity is reached.

Another reconfiguration command allows any number of machines on thenetwork to be combined in a common jackpot having a common jackpotpayout schedule, wherein the reconfiguration command reconfigures theselected machines to payout in accordance with the common jackpot payoutschedule. In this case, the reconfiguration message would be queued upfor each of the selected machines to be combined in a common jackpot.One example of a common jackpot is a progressive jackpot. Unlike theprior art progressive jackpot systems, however, the progressive jackpotaccording to the invention is not limited to a predetermined number ofmachines. In the prior art progressive jackpot systems, a bank ofmachines are connected to a common progressive jackpot controller andonly those machines can be included in the progressive jackpot. Incontrast, any machine on the network, including those connected to otherfloor controllers can be combined into a common progressive jackpot.Moreover, the number of progressive jackpots is not limited by thenumber of floor controllers since one floor controller can manage morethan one progressive jackpot.

Another reconfiguration command permits the system to implementso-called “automatic mystery jackpots.” These “mystery” jackpots allow amachine to payout a mystery jackpot even when a jackpot was not won.Instead, the reconfiguration command can specify that the mysteryjackpot is to occur after a certain number of coins, a certain number ofhandle pulls, or a variety of other conditions specified by thereconfiguration commands. These mystery bonuses provide the casino withanother way to induce additional gaming activity.

5. Bonus Control

Referring now to FIG. 34, a method 550 for controlling the conditionsunder which the above-described bonus activities are activated is shown.It is essential for the system to have complete control over the amountand conditions under which a bonus is paid out in order to insure theprofitability of the bonusing system. The method 550 described belowprovides the required control.

The method 550 begins in step 552 by disabling or turning off thebonuses in the individual machines. This is accomplished by sending amessage to the individual DCNs to turn off or deactivate bonusing. Next,the floor controller monitors the activities of the individual machinesconnected thereto. This step includes monitoring the coins in andbonuses paid for the individual machines, as described above. In step556, the floor controller modifies a bonus pool by a predeterminedpercentage of all coins played. The bonus pool is essentially a pool ofmonetary resources that can be allocated for bonus awards. In thepreferred embodiment, a predetermined percentage of the monetary valueof the coins played are added to the bonus pool. Also in this step, anybonuses paid by the gaming devices are also measured and subtracted fromthe bonus pool. The use of the bonus pool will become more apparent whenthe other steps are described hereinbelow.

In step 558, the floor controller determines whether or not bonusing isactive. If bonusing is active, the floor controller next determineswhether the bonus pool amount has dropped below a predetermined minimumlevel called the “turn-off” level in 560. This minimum amount or floorcan be set by the casino and provides a buffer to account for largebonus awards and/or multiple bonus awards that could cause the bonuspayout to exceed the bonus pool. Therefore, if the bonus pool dropsbelow the turn-off level, the method 550 branches back to step 552 andturns off bonusing. As will described further below, the bonusingremains off until such time as the bonus pool builds up past anotherminimum level called the “turn-on” level.

Returning to step 558, if the bonus is currently not active, the floorcontroller determines at step 562 whether the bonus pool has reached apredetermined turn-on level. This turn-on level can also be set by thecasino and provides a buffer above the turn-off level to insure that thebonusing does not behave erratically, i.e., bonusing rapidly switchingbetween on and off. If the bonus pool is not above the turn-on level,bonusing is again turned off in step 552.

If the bonus pool has reached the turn-on level, the floor controllerchecks to see whether other bonus conditions are met at step 564. Thesebonus conditions can include, but are not limited to, a minimum periodof time since the last bonus activation, a minimum level of play in thetime period prior to the bonus pool reaching the turn on level, apredetermined time of day, or other predetermined conditions. Theseconditions give the casino additional control over the bonusingpromotions. If the conditions are not met, the method 550 branches backto step 552 where the bonusing is again turned off. If, however, theconditions are met in step 564, the bonus is turned on at step 566 andthe method 550 branches to step 554 where the machine activity is againmonitored.

In the preferred embodiment, the method 550 is embodied in software thatis executed by each of the floor controllers in the system. These floorcontrollers are then responsible for activating or deactivating thebonusing for the individual machines connected thereto. The systemallows the floor controller to have multiple bonus pools and to havecertain of the machines associated with a given bonus pool. Thus, thefloor controller can implement multiple bonusing promotionssimultaneously.

This system also allows for machines connected to different floorcontrollers to be combined into a single bonusing promotion. In thiscase, one of the floor controllers assumes primary responsibility formanaging the bonus pool while the other floor controllers act asintermediaries between the primary floor controller and the machinesconnected to the other floor controllers. Thus, the system according tothe invention allows for much greater flexibility in running bonusingpromotionals than heretofore possible. Prior art systems requiredcertain predetermined machines to be connected into a bank for any givenbonus award such as a progressive bonus. The system according to theinvention allows any machine in the casino to be combined in a bonustype situation. The system also insures that the bonusing promotionalswill operate substantially in the black, i.e., the bonus pool is greaterthan the bonus payouts.

Having described and illustrated the principles of the invention in apreferred embodiment thereof, it should be apparent that the inventioncan be modified in arrangement and detail without departing from suchprinciples. For example, although an Ethernet network was described inthe preferred embodiment of the invention, other high-speed networkssuch as wireless networks could be used in place thereof. I claim allmodifications and variation coming within the spirit and scope of thefollowing claims.

1. A method of providing a game on a gaming machine, said methodcomprising: receiving an input signal indicating a wager amount on aplay of the game; determining an outcome to the play of the game;determining a first award associated with the outcome according to apayout schedule stored on the gaming machine; and determining whether topay a second award in addition to the first award wherein the outcomedetermined for the play of the game is not used to determine whether topay the second award.
 2. The method of claim 1, wherein the second awardis paid on a random basis.
 3. The method of claim 1, wherein thedetermination of whether to pay the second award depends upon the wageramount.
 4. The method of claim 1, further comprising: calculating arandom value wherein the determination of whether to pay the secondaward depends upon the random value.
 5. The method of claim 1, whereinthe determination of whether to pay the second award depends upon a sumof wagers made during the play of a plurality of games.
 6. The method ofclaim 1, wherein the determination of whether to pay the second awarddepends upon a number of games initiated.
 7. The method of claim 1,wherein the determination of whether to pay the second award dependsupon a sum of wagers made during the play of a plurality of games over atime period.
 8. The method of claim 1, wherein the determination ofwhether to pay the second award depends upon a number of games initiatedover a time period.
 9. The method of claim 1, further comprising:outputting to at least one display one or more of the outcome, the firstaward, the second award or combinations thereof.
 10. The method of claim9, wherein the at least one display is one of a mechanical display or avideo display.
 11. The method of claim 1, wherein the second award is aprogressive award.
 12. The method of claim 1, further comprising:receiving from a remote host a second award amount for the second award.13. The method of claim 1, further comprising: selecting from aplurality of award amounts a second award amount to pay for the secondaward.
 14. The method of claim 13, further comprising: receiving from aremote host the plurality of award amounts.
 15. The method of claim 1,further comprising: receiving from a remote host a progressive awardamount to pay for the second award.
 16. The method of claim 1,determining a first award amount for the first award to be zero anddetermining a second award amount greater than zero for the secondaward.
 17. A networked gaming system comprising: a floor controller; aplurality of gaming machines operable to communicate with the floorcontroller, wherein each of said plurality of gaming machines includes apayout table for specifying standard payouts payable at each of thegaming machines that correspond to outcomes displayed on each of thegaming machines; wherein each of the gaming machines is configured todetermine whether to provide a bonus payout after an outcome isdisplayed and wherein said bonus payout is in addition to the standardpayouts paid by each of the gaming machines and wherein thedetermination of whether to pay the bonus payout is not based on theoutcome displayed at each of the gaming machines providing the bonuspayout; and wherein the determination of whether to pay the bonus payoutis based, at least in part, on information communicated between thefloor controller and each of the gaming machines providing the bonuspayout.
 18. The networked gaming system of claim 17, wherein the bonuspayout is a progressive award.
 19. The networked gaming system of claim17, further comprising a bonus pool maintained by the floor controller,wherein the bonus pool funds the bonus payout.
 20. The networked gamingsystem of claim 19, wherein a predetermined percentage of coins-inreceived at said plurality of gaming machines is allocated to the bonuspool.
 21. The networked gaming system of claim 17, wherein the floorcontroller and each of said gaming machines providing the bonus payoutare designed to communicate information relating to coin-in at each ofsaid gaming machines providing the bonus payout.
 22. The networkedgaming system of claim 17, wherein said bonus payout is provided inresponse to a bonus event being triggered one of the gaming machines.23. The networked gaming system of claim 22, wherein in response to thebonus event being triggered, at least one additional outcome isdisplayed prior to providing the bonus payout.
 24. The networked gamingsystem of claim 17, wherein a first bonus payout is provided on a firstgaming machine at proximately a same time as a second bonus payout isprovided on a second gaming machine.
 25. The networked gaming system ofclaim 17, wherein networked gaming system is operable to allow the bonuspayout to be triggered on only one gaming machine at a time.
 26. Thenetworked gaming system of claim 17, wherein information transmittedbetween the floor controller and one or more of the plurality of gamingmachines is used to provide the bonus payout.
 27. A networked gamingsystem comprising: a remote host; a plurality of gaming machinesoperable to communicate with the remote host, each gaming machinecomprising: a display for displaying a game; a first input mechanismoperable to receive money or indicia credit for wagers on a play of thegame; a second input mechanism operable to receive an input indicating awager amount on the play of the game; at least one processor operable toexecute software for controlling the play of the game; at least onememory for storing the software and a payout schedule wherein thesoftware comprises; a) logic for determining an outcome for the play ofthe game and a first award associated with the outcome wherein the firstaward and the outcome are related according to information stored in thepayout schedule; b) logic for determining whether to pay a second awardin addition to the first award wherein the outcome determined for theplay of the game is not used to determine whether to pay the secondaward; a communication interface for communicating with the remote host;and a network for allowing communications between the remote host andthe plurality of gaming machines.
 28. The networked gaming system ofclaim 27, wherein the second award is a progressive award.
 29. Thenetworked gaming system of claim 28, wherein the remote host is operableto calculate a progressive award amount for the progressive award usingwager information received from the plurality of gaming machines. 30.The networked gaming system of claim 27, wherein the remote is operableto communicate an award amount for the second award to each of theplurality of gaming machines.
 31. The networked gaming system of claim27, wherein the determination of whether to pay the second award is madeon a random basis.
 32. The networked gaming system of claim 27, whereinthe determination of whether to pay the second award depends on a numberof games initiated by a particular user.
 33. The networked gaming systemof claim 27, wherein the determination of whether to pay the secondaward depends on a sum of wagers made during the play of a plurality ofgames by a particular user.
 34. The networked gaming system of claim 27,wherein the determination of whether to play the second award depends ona randomly calculated value.
 35. The networked gaming system of claim27, wherein each gaming machine is operable to provide a second awardamount greater than zero for the second award when a first award amountfor the first award is zero.